Должен ли я придерживаться плохих правил именования?

Question

Я сейчас работаю над сайтом, который прошел бог знает сколько рук у разработчиков. Одна из вещей, которые мне не нравятся, это то, что каждая таблица в базе данных имеет префикс "tbl_" и каждое поле "fld _".

Я начал работу над новой функцией и столкнулся со следующей проблемой: должны ли мои новые таблицы продолжать прежнее соглашение или нет?

Я думаю, что должен, но я чувствую себя глупо, делая это:)

Answer 1

Я бы придерживался того же соглашения. Независимо от того, плохо это или нет, по крайней мере, оно будет последовательным И согласованность будет очень важна для следующего разработчика, который овладеет кодом.

Answer 2

Будучи подрядчиком, я много сталкиваюсь с этой проблемой. Вот мои 2 цента:

Если это не сломано, тогда клиент тратит свои деньги, заставляя меня это изменить. Если я не переписываю все приложение, я обычно придерживаюсь старых (плохих) стандартов (по крайней мере, так, у вас нет части приложения с одним соглашением, а другие части используют что-то другое - это делает код читаемым для других разработчики).

Answer 3

У вас есть два варианта.

1. Измените все соглашения о недопустимых именах на новые.
2. Используйте старые соглашения.

Кто-то рассмотрит этот код позже, и ему придется иметь дело с любыми различиями, которые вы создаете. Это означает, что вы должны знать, что это решение влияет на других людей. Делайте правильные вещи, если у вас есть время, делайте уродливые вещи, если у вас нет времени ... но держите их в порядке.

Answer 4

Я склонен смотреть на масштаб. Для меня непротиворечивость соглашения о плохом именовании предпочтительнее, чем множество разных в одной и той же кодовой базе или базе данных.

Если есть несколько столов, и вы можете смело их менять, я чувствую, что нужно внести изменения. Но что-то масштабное или приложение, в котором вы исправляете только ошибку, скорее всего, не стоит затраченных времени и усилий.

Answer 5

Если бы это был постоянный стиль в приложении, я бы следовал соглашению об именах, это облегчит работу следующего разработчика.

Answer 6

Любое соглашение об именах лучше, чем отсутствие / несогласованное соглашение об именах.

Answer 7

Добро пожаловать в мир технического обслуживания. ;)

Кто скажет, что следующий человек, работающий на сайте, не будет презирать то, как вы это делали?

Answer 8

Я думаю, вы должны предпочесть последовательность и следовать уже используемой конвенции.

Подумайте о бедных разработчиках, которые идут за вами и сталкиваются с двумя различными соглашениями об именах (исходное и новое), ни одно из которых не нравится новым разработчикам.

Answer 9

«Если не сломано, не чините»

Answer 10

Отправляйтесь с любым маршрутом, который стоит дешевле, деньгами и ресурсами. Если это не поможет вам сэкономить, пройдя и перерабатывая землю, то не делайте этого. Просто стисни зубы и двигайся вперед.