Что делает «хороший стиль» в Java? [закрыто]

9

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

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

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

Что вы думаете о том, чтобы создать хороший, хорошо разработанный код?

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

Изменить: спасибо за все хорошие ответы / комментарии до сих пор. Я особенно заинтересован в ответах, которые помогли бы систематизировать те вещи, которые заставляют совесть программиста (и, возможно, желудок) взломать?

amaidment
источник
Среди прочего, перечисленного здесь, я бы определенно констатировал, что компьютеры могут компилировать код практически любым способом, который вы пишете, но в конечном итоге код должен быть удобочитаемым . Комментарий как сумасшедший! Хороший тест, который мне нравится использовать: может ли человек читать только мои комментарии, чтобы узнать, что делает код, какими должны быть его входы и выходы, и какой алгоритм (ы) использовали для этого?
Брайан
1
@ Брайан, заставь свой код объяснить, как . Оставьте реальные комментарии, чтобы объяснить, почему . Другими словами, не комментируйте как сумасшедшие (в общем случае)
4
Брайан: Эта техника определенно не считается хорошей практикой. Общепринятой практикой является стремление сделать ваш код максимально самодокументированным (с четкими именами переменных и согласованием функций) с комментариями, объясняющими «почему», а не «как». Комментарии, которые объясняют каждую мелочь, обычно считаются отвлекающими и часто опасными, поскольку люди реже поддерживают комментарии, чем код.
Кейси Паттон
1
@ Брайан: Ваше последнее заявление говорит все это. Код должен быть доступен для чтения. Комментарии становятся несвежими. Код никогда не делает. Если вы чувствуете необходимость в комментариях, проводите рефакторинг до тех пор, пока код не станет настолько ясным, что комментарии будут просто повторять то, что написано в коде. Единственный хороший комментарий - тот, который говорит, почему код работает особым образом - например, чтобы избежать ошибки в сторонней библиотеке - чтобы кто-то не вернулся и не изменил ее на что-то, что не будет работать по причине это не сразу видно
Райан Стюарт
2
Я был официально унижен. Извините @maidment. Я думаю, что нужно исследовать хорошие стандарты кодирования, когда дело доходит до комментариев.
Брайан

Ответы:

17

Несколько кратких замечаний:

Райан Стюарт
источник
3
+1. Возможно, самое важное: минимизировать дублирующийся код. Если у вас возникнет желание вырезать и вставить несколько токенов, вам нужно извлечь функцию. Даже если функция представляет собой одну строку кода.
Кевин Клайн
4
В отношении дублированного кода я придерживаюсь следующей позиции. Вырезать и вставить = все в порядке. Это просто перемещение кода (при условии, что вы используете вставить один раз). Скопируйте и вставьте = ужасно. Если вы просто удалите кнопку копирования из своего словаря, вы, скорее всего, поступите правильно.
Йтернберг
@jsternberg: +1 за различие в вырезке / копировании, но я заметил, что многие люди говорят «вырезать / вставить», когда имеют в виду «копировать / вставить». Я не знаю, как различие было потеряно.
Райан Стюарт
5
Не повторяйся. Не повторяйся. Не повторяйся.
конфигуратор
1
@configurator, ты пахнешь немного смешно ...
9

Добавление в список Райана:

  • Следуйте твердым принципам
  • Убедитесь, что ваш код не имеет слишком большой циклической сложности
  • Test Driven Java - это всегда хорошо
  • Если у вас есть xFactoryFactoryкласс, вы делаете это неправильно :-)
  • Учитывая библиотеки с открытым исходным кодом в экосистеме Java, переизобретать колесо - плохой стиль
  • Используйте время Joda для даты и времени

Я остановлюсь там.

Мартейн Вербург
источник
2
Но как насчет HammerFactoryFactoryFactoryкласса? ;-)
Уэйн Молина
@Wayne, Фабрики являются показателем того, что некоторые решения должны быть отложены, а FactoryFactoryFactories указывают, что есть решение, которое действительно необходимо принять во время выполнения, но не может.
Я знаю, я был саркастичен и ссылался на ту статью о том, почему тогда J2EE был слишком сложным, с HammerFactories и HammerFactoryFactories, и я думаю, HammerFactoryFactoryFactories. :)
Уэйн Молина
@Martijn - спасибо за твёрдую ссылку; Я не сталкивался с этим раньше. Вы предлагаете использовать JodaTime; это просто (соответствующее) отвращение к классам Java Calendar / Date? Как насчет JSR310 (преемник JodaTime)?
удивление
Мы надеемся, что JSR-310 превратится в Java 8 (многие из нас собираются, чтобы попытаться помочь этому, свяжитесь со мной, если хотите принять участие). В то же время время Joda является стандартным стандартом для работы с датой и временем в Java. В Java-системе Date and Calendar так много проблем, что я даже не знаю, с чего начать ;-). Убийца в том, что Даты изменчивы и что нет понятия мгновенного или периода или ... Нет, я остановлюсь там :-).
Мартейн Вербург
1

Оценивая ответы других, я подумал, что было бы справедливо поделиться некоторыми вещами, о которых я думаю, когда пытаюсь написать хороший код:

  • что нужно знать об этом классе / методе / переменной? т.е. где должны жить эти знания?

  • как этот код может повлиять на память / производительность моего приложения? (Я признаю, что «преждевременная оптимизация - это корень всего зла»; поэтому я не предлагаю тратить много времени на оптимизацию, а скорее на сознание при первоначальном написании моего кода.)

  • ясно (из кода и структур кода), что это делает? (Я стараюсь следовать принципу: «Старайся не дать людям понять, старайся сделать так, чтобы люди не могли понять неправильно».)

amaidment
источник
1

Прочитайте класс String и ArrayList, чтобы найти отличные примеры правильного программирования на Java. Но они очень лаконичны, почти в стиле C, что не обязательно лучше для поддерживаемого кода с минимальным количеством документов Java. Обычная практика в моем магазине - отсутствие комментариев, поэтому я стараюсь комментировать по коду, используя подробные имена переменных camelCase и чрезмерное использование новых строк, чтобы отделить одну точку зрения от другой. Я до сих пор спорю, используя вкладки, чтобы отделить переменные от их значений. Вкладки могут улучшить читаемость, IMO, но только тогда, когда они сделаны минимально, и это очень субъективно. Я считаю, что это действительно об аудитории. Там нет лучшего ответа здесь.

carlmart
источник