Що означає «хороший стиль» на Java? [зачинено]


9

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

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

Але що робить «гарний стиль»? Як і багато речей, я це знаю, коли бачу це ... але я хотів мати краще уявлення, ніж просто моя совість, кажучи, що ця конструкція не вважає себе правильною.

Які речі ви думаєте, щоб створити хороший, добре розроблений код?

(Я визнаю, що це дещо суб'єктивно, оскільки те, що є «хорошим стилем», залежатиме від завдання, яке стоїть перед вами). (Також я хочу додати, що мене не цікавлять стилі команди - наприклад, "ми використовуємо відступи з 2 пробілів, а не 4" ..., і мене не цікавлять умови коду Java.)

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


Серед багатьох інших речей, перерахованих тут, я б точно переконався, що просто констатую, що комп’ютери можуть складати код практично будь-яким способом, який ви пишете, але в кінцевому рахунку, код повинен бути зрозумілим для людини . Коментуй як божевільний! Хороший тест, який я люблю використовувати: чи могла людина читати лише мої коментарі, щоб дізнатися, що робить код, якими він повинен бути вхід та вихід та алгоритм (и), які використовуються для цього?
Брайан

1
@brian, зробіть свій код, поясніть як . Залиште фактичні коментарі, щоб пояснити, чому . Іншими словами, не коментуйте як crazy (у загальному випадку)

4
Брайан: Ця техніка, безумовно, не вважається хорошою практикою. Поширена добра практика полягає в тому, щоб зробити свій код максимально самодокументованим (з чіткими назвами змінних та функцією згуртованості), з коментарями, щоб пояснити "чому", а не "як". Коментарі, що пояснюють кожну дрібницю, зазвичай вважаються відволікаючими та часто небезпечними, оскільки люди рідше підтримують коментарі, ніж код.
Кейсі Паттон

1
@Brian: Ваше останнє твердження говорить про це все. Код повинен бути доступний для читання. Коментарі старі. Кодекс ніколи не робить. Якщо ви відчуваєте потребу в коментарях, рефактор, поки код не стане настільки зрозумілим, що коментарі просто повторюють те, що йдеться в коді. Єдиний хороший коментар - це те, що говорить, чому код працює певним чином - як уникнути помилки в сторонній бібліотеці - щоб хтось не повертався назад і міняв його на щось, що не працюватиме з причини це не відразу видно.
Райан Стюарт

2
Я офіційно принижений. Вибачте @amaidment. Напевно, потрібно вивчити хороші стандарти кодування, коли мова йде про коментарі.
Брайан

Відповіді:


17

Кілька коротких моментів:


3
+1. Мабуть, найважливіше: мінімізувати дублюваний код. Якщо ви спокусилися вирізати та вставити більше декількох жетонів, вам потрібно витягнути функцію. Навіть якщо функція - це один рядок коду.
Кевін Клайн

4
Що стосується дублюваного коду, я приймаю таку позицію. Виріжте і вставте = добре. Це просто переміщення коду (якщо ви використовуєте пасту один раз). Скопіюйте та вставте = жахливо. Якщо ви просто видалите кнопку копіювання зі свого словника, ви, швидше за все, зробите правильно.
jsternberg

@jsternberg: +1 для розрізання / копіювання, але я помічаю, що багато людей кажуть "вирізати / вставити", коли вони означають "копіювати / вставляти". Я не знаю, як була втрачена відмінність.
Райан Стюарт

5
Не повторюйте себе. Не повторюйте себе. Не повторюйте себе.
конфігуратор

1
@configurator, ти трохи смішно

9

Додавання до списку Райана:

  • Дотримуйтесь принципів SOLID
  • Переконайтесь, що ваш код не має надто великої циклічної складності
  • Тестова версія Java - це завжди добра річ
  • Якщо у вас є xFactoryFactoryклас, ви робите це неправильно :-)
  • Враховуючи бібліотеки з відкритим кодом в екосистемі Java, переосмислити колесо - це поганий стиль
  • Використовуйте час і час для дати та часу

Я зупинюсь там.


2
А як щодо HammerFactoryFactoryFactoryкласу? ;-)
Уейн Моліна

@Wayne, Заводи - це вказівка ​​на те, що деякі рішення потрібно відкласти, а FactoryFactoryFactories вказують, що є рішення, яке дійсно потрібно прийняти під час виконання, але не могло.

Я знаю, я говорив про саркастичну і посилався на цю статтю про те, чому тоді J2EE був надмірно складним, з HammerFactories і HammerFactoryFactories, і я думаю, що HammerFactoryFactoryFactories. :)
Уейн Моліна

@Martijn - дякую за посилання SOLID; Я раніше не стикався з цим. Ви пропонуєте використовувати JodaTime; це просто (відповідне) відраза до класів Java Calendar / Date? Що з JSR310 (спадкоємцем JodaTime)?
подив

JSR-310, сподіваємось, перетворить його на Java 8 (є низка з нас, яка намагається допомогти зробити це, зв’яжіться зі мною, якщо ви хочете долучитися). Тим часом, час Joda - це дефоктна обробка для дати та часу на Яві. З системою дати та календаря Java так багато не так, що я навіть не знаю, з чого почати ;-). Вбивця полягає в тому, що Дати змінюються і що немає поняття миттєвого або періодичного періоду або ... ні, я зупинюсь на цьому :-).
Martijn Verburg

1

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

  • що потрібно знати про цей клас / метод / змінну? тобто де повинні жити ці знання?

  • як цей код може вплинути на пам'ять / продуктивність моєї програми? (Я визнаю, що "передчасна оптимізація - корінь усього зла", тому я не пропоную витратити багато часу на оптимізацію, а скоріше свідомість, спочатку пишу свій код.)

  • чи зрозуміло (з коду та структури коду), що це робить? (Я намагаюся дотримуватися максимуму: "Прагніть не робити можливим, щоб люди розуміли, прагніть зробити так, щоб люди не могли зрозуміти неправильно".)


1

Прочитайте клас String і ArrayList, щоб отримати відмінні приклади правильного програмування Java. Але вони відрізняються високою стислістю, майже стилем C, що не обов'язково найкраще підходить для бездоганного коду з мінімальними документами Java. Поширена практика в моєму магазині - це не коментарі, тому я намагаюся коментувати за кодом, використовуючи багатослівні назви camelCase var та надмірне використання нових рядків, щоб відмежувати одну думку від іншої. Я все ще дискутую, використовуючи вкладки, щоб відокремити значення від їх значень. Вкладки можуть покращити читабельність, IMO, але лише тоді, коли робиться мінімально, і це дуже суб'єктивно. Я вважаю, що це дійсно про аудиторію. Тут немає найкращої відповіді.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.