Автоматическое форматирование код [закрывается]

Чтобы скрыть элементы в Visual Studio, добавьте свойство метаданных Visible к элементу. Метаданные InProject, по-видимому, тоже это делают.

Видимый: http://msdn.microsoft.com/en-us/library/ms171468 (VS.90) .aspx

InProject: http: // blogs.msdn.com/b/jomo_fisher/archive/2005/01/25/360302.aspx


  
    
    false
    
    false
  

6
задан Yaneeve 4 November 2009 в 14:52
поделиться

12 ответов

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

8
ответ дан 8 December 2019 в 02:16
поделиться

I disagree with you. For me, the formatting, even if it is only a way to "present" the source code, is also an important code quality indicator.

Using the auto-formatting has several advantages. It homogenizes the format among all the developers of the team. This will avoid you some troubles with the SCM manipulation: for example, merging two files that have few real changes, but a lot of formatting differences is a nightmare!

It can also show you some errors. For example:

if (aCondition)
    foo();
    bar();

will be reformatted:

if (condition)
    foo();
bar();

showing that the second line is not in the if statement.

Last, but not least, a well formatted code (not only for Java) is easier to read!

16
ответ дан 8 December 2019 в 02:16
поделиться

Согласованное форматирование кода действительно помогает в различении и тому подобном при отправке кода.

Я настроил свои сценарии управления версиями на автоматическое форматирование в «домашний стиль» при нажатии и автоматическое форматирование в соответствии с моим предпочтительным стилем тяги, так что все будут довольны.

Я рекомендую вам подумать о том же.

3
ответ дан 8 December 2019 в 02:16
поделиться

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

Проблема с автоформатом для меня в основном в том, что он нарушает систему управления версиями. Однако однократное преобразование форматирования - без каких-либо других изменений - вполне может улучшить рабочий процесс.

5
ответ дан 8 December 2019 в 02:16
поделиться

Код форматирования чрезвычайно важен:

  • Сохранение кода с правильным отступом упрощает навигацию по файлам среднего и большого размера для пользователя.
  • Сохраняя постоянный стиль кодирования во всех проектах, когда люди переходят к другим проектам, они будут более знакомы с кодом. Конечно, это также связано с рекомендациями по кодированию, как называть переменные и т.д., которые также должны быть относительно нормализованы в общих чертах.
  • Если вы потратите некоторое время на выполнение правильных правил форматирования кода, вы также гарантируете, что код будет доступен большему количеству пользователей (к сожалению, мне приходилось редактировать код вручную в тексте [например, в блокноте или emacs] вручную). Установка длины строки на 80 столбцов или около того может помочь)
  • Самое главное, change is the formatting with a commit message that reflects that this was all that changed, then go back and make your actual code changes. This will save you a lot of time when you need to diff changes. The format revision will have nearly every line of code changed, so it will be practically impossible to find a real change on the same revision.

  • Agree upon a coding standard and customize Eclipse's auto-format tool чтобы следовать этому стандарту.

3
ответ дан 8 December 2019 в 02:16
поделиться

Depends on what you mean by "disorganized." Are we talking about stylistic inconsistencies, or is the class structure an unintelligible hodge-podge? I'm guessing the former if you're addressing it through an auto-formatter.

"Proper coding" doesn't necessarily mean "consistent across developers". If I have my editor set to four-space hard tabs and you have yours set to three-space soft tabs, code we both work on is going to look like ass. (And our project manager should probably thwack us both upside the head and let us know what standard we SHOULD be using.)

The auto-formatter is a bit of a brute force solution and is pretty much guaranteed to occasionally turn something unusual but perfectly readable into a mess. If the code is really that much of a mess, it's a sensible starting point. But once you've auto-formatted the bulk of the Suck out of the pre-existing code, you're better off establishing the team's preferred style conventions and proceeding from there.

2
ответ дан 8 December 2019 в 02:16
поделиться

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

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

2
ответ дан 8 December 2019 в 02:16
поделиться

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

Но, как уже говорилось, я бы использовал автоформатирование один раз при рефакторинге файла.

1
ответ дан 8 December 2019 в 02:16
поделиться

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

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

Если у вас есть действенные примеры того, как автоформат делает код сложнее читать, вы можете поделиться ими со своим начальником, но, честно говоря,

1
ответ дан 8 December 2019 в 02:16
поделиться

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

При этом наличие хорошо отформатированного кода критически важно для написания надежного программного обеспечения.

0
ответ дан 8 December 2019 в 02:16
поделиться

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

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

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

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

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

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

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

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

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

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

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

1
ответ дан 8 December 2019 в 02:16
поделиться

Код форматирования чрезвычайно важен:

  • Сохранение кода с правильным отступом упрощает навигацию по файлам среднего и большого размера для пользователя.
  • Сохраняя постоянный стиль кодирования во всех проектах, когда люди переходят к другим проектам, они будут более знакомы с кодом. Конечно, это также связано с рекомендациями по кодированию, как называть переменные и т.д., которые также должны быть относительно нормализованы в общих чертах.
  • Если вы потратите некоторое время на соблюдение правил форматирования кода, вы также гарантируете, что код будет доступен большему количеству пользователей (к сожалению, мне приходилось редактировать код вручную в тексте [думаю, блокнот или emacs] вручную. Установив длину строки на 80 столбцов или около того, это может помочь)
  • Самое главное, сохраняя единообразное форматирование, вы можете гораздо проще различать два файла
0
ответ дан 8 December 2019 в 02:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: