Цитата:
Сообщение от
glibs
возможно "_RU" нужно было для того, чтобы отличать локализаторские доработки от проектных.
К слову, суффиксы по странам в локализации очень сильно упрощают понимание того, какое поле/метод/таблица/класс для какой страны предназначены и насколько в твоем конкретном случае применимы и нужны. К примеру, скрипты обновления данных отчасти грешат тем, что не всегда увязывают выполнение того или иного метода с конфигурационным ключом для соответствующей страны. Так вот, когда нужно ускорить процесс конвертации базы при обновлении, то, видя такие суффиксы в названиях методов или обрабатываемых в них полей/таблиц, сразу понимаешь, что их можно безболезненно отключить. Аналогично с полями таблиц в повседневной работе: если есть какое-то "многообещающее" по названию поле, но с суффиксом от явно не используемой на данном проекте локализации, сразу понятно, что рассчитывать на него не стоит.
Но тут ситуация сильно отличается от того, что обсуждается в данной теме: стандартное приложение поставляется "как есть" - без всяких там историй в системе контроля версий и документации по запросам, на основании которых появились те или иные поля/таблицы/классы, в то время как для доработок такая дополнительная информация как минимум
может (если не
должна) быть обеспечена разработчиками.
Цитата:
Сообщение от
sukhanchik
В свое время довелось мне спорить с Валерием Ушаковым (VALU - для тех кто знает - отвечал некоторое время за разработку АХ в МС) по поводу оформления смысловых комментариев в коде. Он был противником любых комментариев в коде.
К счастью, подход MS в целом к комментированию кода стандартного приложения коренным образом изменился.
Цитата:
Сообщение от
sukhanchik
В качестве убийственного аргумента, с которым я не смог не согласиться был довод - что любая документация нуждается в обновлении при изменении кода. Т.е. если я пишу в качестве комментария - описание того, что делает тот или иной класс/метод, то при изменении кода - я обязан изменить комментарий (а это лишнее время).
Лишнее для кого? Если не писать никаких комментариев, то это - лишнее время для того, кто будет поддерживать и развивать код. Экономя время на написании комментариев при модификации, воруешь это самое время у других, а весьма вероятно, что и у самого себя, потому что через год-два может понадобиться разбирать и модифицировать свой же код.
Цитата:
Сообщение от
sukhanchik
наличие корректных комментариев (=корректная ссылка на документацию) помогает разобраться в коде, а наличие некорректных комментариев (=некорректная ссылка на документацию) - только мешает. Отсутствие комментариев - действует нейтрально. Теперь - зададимся все вопросом - мы всегда обновляем свои и чужие комментарии в коде при его изменении? А если эта ссылка "зашита" в название поля/метода/объекта?
За "мы" не скажу - я обновляю и, порой, комментирую чужой код, если при модификации нахожу какие-то моменты трудными для (собственного) понимания или важными по неочевидным причинам. Если же в названии поля/метода объекта написано одно, а вы делаете так, что смысл получается совсем иной (скажем, в методе написано validate, а вы в нем начинаете данные править), то это явно указывает на ошибки в проектировании - либо у исходного автора, либо у того, кто вносит модификации. Что мешает переименовать поле/метод, чтобы название корректно отражало "новые реалии"? Опять время экономим?
См. также
исправление имён