Можно ли использовать разный стиль именования в бд и в коде?
Использую camelCase в коде(переменные, классы, функции) и snake_case в бд(названия таблиц, столбцов, самих бд), уже не помню почему, но пишу всегда так. Считается ли это нормальным или кто-то, кто работал над сайтами, которые я раньше писал, проклинает меня за это?
Ну в ЯП есть стандарты по именованию можно погуглить PSR.
В БД свои стандарты именования, в SQL обычно camel_case, так что это нормально, что у вас названия в базе и в коде различаются, мне лично никакого дискомфорта не доставляет.
Наоборот бесит, когда человек пришел с какой-нибудь Java в PHP и именуют потом в стилях headerElement {}.
Требований к строгому следованию стилям нет ни в одном языке программирования. То, что в вас бесится перфекционист вашего личного стиле-оформления, так звиняйте, мужики то не в курсах!
Andrew Stark, ссылку в документации любого языка программирования на "стандарт" стилевого оформления переменных, классов, программного кода приведёте?
Пожалуйсте не надо приводить примеры книг каких-либо авторов, пишущих о том или ином языке программирования. Именно на документированные "стандарты" прошу вас ссылаться.
Да, я не отрицаю, что многими программистами сообщества выработаны некие стили оформления, но они не являются стандартами для какого-то конкретного языка, а необходимы только для удобства восприятия кода и носят исключительно рекомендательный характер.
Дмитрий Добрышин, Надеюсь вы в курсе про PSR? И да, все PSR нотации носят рекомендательный характер, но и придуманы не для понтов, есть очевидный и четкий резон в том, что код пишется в едином стиле, т.к. сегодня любой толково написанный компонент можно подключить через композер(что возможно благодаря PSR-0), и все они стараются придерживаться стандартов кода для того, что бы при прочтении кода компонентов у разработчика не вскипел мозг и не косели глаза от различного стиля кода в разных кусках проекта. Это как бы соглашение на основе взаимоуважения. Если вы хотите чтобы вас воспринимали как коллегу с чувством ответственности за свой код, придерживайтесь общих правил оформления. Это и дисциплинирует в плане аккуратности, и код реально читается легче.
ThunderCat, я в курсе. Вы так же, надеюсь, знакомы с коммерческим кодом, который с целью усложнения понимания алгоритма как раз таки обфусцирован и иными способами закодирован.
Чего только стоят переменные, классы и методы внутри классов, все как на подбор названные a, b, c.
Да библиотеки документированы, но залезть и понять что же внутри коммерческой библиотеки ой как непросто.
Дмитрий Добрышин, не не не, не надо путать мягкое с теплым. Стиль оформления кода и методы его сокрытия суть вообще разные вещи. Тут вроде как раз читаемость обсуждается.
ThunderCat, так я ниже в ответе написал - что можно придерживаться, а можно не придерживаться по усмотрению разработчика. И что игнорирование общепринятого считается плохим тоном.
Простой
Простой
