Является ли стандарт кодирования очень важным для каждой программы, которую пишет разработчик? - PullRequest
0 голосов
/ 26 декабря 2009

Я хочу, чтобы наши коллеги-разработчики отвечали на некоторые вопросы, касающиеся стандартов кодирования.

  • Правда ли, что о разработчике судят по его стандарту кодирования?
  • Каковы наилучшие практики стандартов кодирования, которым можно следовать в веб-приложении?
  • Каковы общие стандарты кодирования, которые начинающие разработчики не могут адаптировать в своем приложении?

Ответы [ 8 ]

3 голосов
/ 26 декабря 2009

В мой первый год работы в крупной и уважаемой компании с блестящими инженерами архитектор выкрикнул меня за то, что я написал if(foo) вместо if (foo) - я попросил его объяснить, и он сказал: " ЕСЛИ это не функция. Не делай этого. "

Я рад, что ты думаешь об этом. Кодирование «стандартов» означает разные вещи в зависимости от того, где вы находитесь - есть все: от простого «стиля» (куда вы помещаете свои фигурные скобки) до шаблонов (такого рода вещи должны быть единичными, такого рода вещи должны создаваться с помощью заводского объекта) к указаниям, относящимся к материалу, над которым вы работаете («Здесь, в этом офисе, мы всегда используем такой-то пакет для проверки и дезинфекции веб-параметров, поэтому вы должны его использовать».).

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

1 голос
/ 26 декабря 2009

Стандарты кодирования похожи на хорошее написание. То, что делает хорошее письмо (неотразимым, интересным и т. Д.), Отличается от человека человеку, но есть некоторые вещи, которые универсально верны.

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

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

1 голос
/ 26 декабря 2009

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

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

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

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

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

1 голос
/ 26 декабря 2009

Стандарты кодирования безусловно важны. Это облегчает прохождение кода. Это позволяет автоматизировать код через некоторый шаблонный механизм. Менеджеру проекта легко описать, заинтересовался ли он / она аудитом.

1 голос
/ 26 декабря 2009
  1. Среди прочего, да.
  2. Как и в любом другом приложении: документируйте свои предположения, поскольку они не могут быть прочитаны из кода. (И, конечно, следуйте всем общим правилам, таким как значимые имена, короткие методы и тестирование, тестирование, тестирование.)
  3. Написание тестов.
1 голос
/ 26 декабря 2009

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

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

Это помогает следовать стандартам, с которыми знакомы другие, поскольку это будет в стиле, с которым знакомы другие разработчики, даже если они сами не следуют этому.

Лучшие практики в веб-приложении сильно зависят от платформы / языка, поскольку то, что будет хорошо работать в PHP5, будет отличаться от ASP или ASP.MVC.

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

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

1 голос
/ 26 декабря 2009

да, абсолютно.

0 голосов
/ 26 декабря 2009

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

...