Если возможно автоформатировать код, прежде и после фиксации управления исходным кодом, контроля, разности, и т.д. компании действительно нужен стандартный стиль кода?

Вот чем мы занимаемся в моей работе:

Все мы используем Eclipse. У нас нет политики использования Eclipse, но почему-то никто из нас не является парнем по IDEA / IntelliJ. Мы также считаем, что наш код должен быть написан с учетом наследия. Это означает, что наш код должен быть читаемым определенным образом даже спустя годы после ( # 1 ), независимо от того, кто его написал и работает ли этот человек в компании.

Eclipse имеет несколько удобных функций, автоматическое форматирование при сохранении и специальный инструмент Formatter . Как видно из связанного снимка экрана, его можно настроить с помощью XML. Таким образом, есть набор готовых XML: s, доступных для каждого сотрудника в нашей компании, так что, когда приходит новый парень, мы проводим его через весь процесс и настраиваем его Eclipse для них ( да, это » ), так что на самом деле используется формат XML: s, который мы предоставили. Мы не , а не применяем автоматический формат при сохранении, мы не хотим быть полностью навязчивыми, мы просто хотим подтолкнуть всех наших разработчиков в правильном направлении. Для еще большей совместимости мы в основном используем правила, определенные в JCC .

Затем идет важная часть, собственно сборки. Мы те, кто использует автоматические сборки, и для этого мы используем Hudson Continuous Integration Server . Помимо этого, в наших конфигурациях есть две важные части:

• Мы используем CVS loginfo для запуска сборки всякий раз, когда что-то фиксируется.
• Мы используем несколько плагинов, доступных для Hudson, включая Continuous Integration Game в сочетании с наиболее важным,

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

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

  И действительно ли это нужно нам как компании? Я думаю, мы поступаем так, как вы должны видеть, прочитав весь этот ответ,

Нет, не совсем.

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

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

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

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

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

В противном случае, если существует большой объем кода, который уже соответствует стандарту магазина, который НЕ является как и у инструментов, у вас есть два варианта:

1. Изменить весь код в соответствии со стандартом инструмента или
2. Поддержать существующий стандарт магазина.

Многие магазины делают последнее. Тем не менее, нужен какой-то стандарт, и ему нужно следовать.

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

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

Основная цель стандартного стиля кода - (ИМХО) гарантировать, что вы можете легко читать код других членов команды без необходимости его обратного проектирования, потому что весь код написан с использованием такие же руководящие принципы. Отступы и круглые скобки кажутся серьезной проблемой, но они очень маленькие и, на мой взгляд,

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