Drive your career as React Developer with Symphony Solutions!
×Закрыть

Де можна переглянути написання «правильного або чистого коду» на Java?

Питання до джава розробників. На яких ресурсах можна переглянути написання «правильного або чистого коду». Бажано з поясненнями.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Такой вопрос, нужно протестировать в юните простой код, но я не могу понять как сделать этот тесе кейс. Хоть куда смотреть:

public class Foo {
  
  
  public void foo (int i) {
    
    //s.add("d");
    
    i += 15;
  }
 
}

А что этот код делает? Какая его функциональность? Из-того, что вы написали, он просто изменяет параметр метода (что вообще говоря является признаком плохого кода)

Такой проект, spring-boot 2.2, java 13, JavaScript frontend.

github.com/javadev/pt-backend

github.com/...​ercises/ExerciseFile.java — а нормальная ли это практика название полей для полей не по конвеншену писать?

Для Entity классов названия переменных с подчеркиванием.

А кто автор этого проекта? И почему он априори признан проектом с хорошим кодом? Просмотрел мельком код — вот например метод на 70 строк, явно не признак хорошего кода, github.com/...​ReportWorkoutService.java

Я автор. Метод с большим числом сторо можно переделать.

Интересно. А какую цель вы преследуете этим проектом? Жаль, что нет readme, вопросов было бы меньше

Там еще много чего можно накопать. Вот например метод с информативным названием calc и параметром value. github.com/...​tion/CurveEstimation.java
И так далее. Я бы его рекомендовал не как пример хорошего кода, а как проект, где можно посмотреть как работает те или технологии.

У меня можешь посмотреть перед сдачей проекта...

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

Я рекомендую книгу Роберта Мартина Clean Code. Он просто и понятно обьясняет как писать чистый код.

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

Так и весь проект, недолго в одну строку написать.

Так вершина программирования — одна большая кнопка «Заебись», которая будет угадывать желания пользователя и исполнять.

И еще чтоб топиками не спамить такой вопрос. Отношение к тестовому заданию? Т.з. сейчас везде дают, и порой просто надо время чтоб понять, не говоря о выполнении. Допустим на генетический алгоритм, НЕОЖИДАННО, особенно когда только начинаешь.

любое тестовое — это возможность попрактиковаться. Делай все что дают :)

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

не всегда те, кто задают такое задание — понимают, что оно значит :)
Делай такую реализацию, как ты её понимаешь ;)

Отношение к тестовому заданию?

Расчитывай, что делаешь его для себя.
Интересно — делаешь, не интересно — не делаешь.

Вывел одну интересную закономерность — там, где дают тестовое задание, внутри обычно трешЪ и угар, что туда и не стоило попадать.
Ни разу не подводило правило. Это если не для новичков.

Вежливо всегда отвечаю — идите нахе.. извините, у меня нет на это времени.

Думай-й.

Напишу статью об этом, не могу держать в себе))

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

Некоторые даже не скрывают :D

Было когда-то «вот у нас на проекте есть такая вот проблема, напишите свой вариант решения этого куска, вот независимый кусочек исходников»

И просят Reusable Component.

Есть одна в Киеве компания, которая просит в качестве тестового задания сделать компонент-аудиоплеер под мобилки :)

Было когда-то «вот у нас на проекте есть такая вот проблема, напишите свой вариант решения этого куска, вот независимый кусочек исходников»

Это кстати 95% — признак веб-студии / студии моб.приложений, работающей с апворком, где моб.разработчики пописывают на Питоне и NodeJS, где всё делается силами людей с 1-2 лет опыта и во главе — разраб-пятилетка, который собирает 🍦💩 из 🧩

Мне вот этот ресурс еще понравился
wiki.c2.com/?SelfDocumentingCode

И еще вот шикарный ресурс на эту тему
refactoring.guru/ru

1. sourcemaking.com
— подивись паттерни, використовуй їх if applicable
— подивись антипаттерни, уникай їх
— продивись рефакторинг ідеї, можеш використовувати їх
2. Юзай JUnit тести. Гавнокод важко покрити тестами — вилазить дуже багато штук. В процесі написання тестів (якщо ти не робив їх по TDD) зробиш рефакторинг
3. Класика, про яку вже всі сказали — www.amazon.com/...​aftsmanship/dp/0132350882
4. Нео-Класика: habr.com/...​ompany/piter/blog/418157. І отут якраз виникає основна причина гавнокоду. Кожен програміст може сказати: «я художник, я так вижу». Єгор Бугаєнко норм чувак, але його погляди на ООП, на стиль написання коду можуть викликати дуже різні емоції... кардинально різні) Думаю ви в курсі)

Начать нужно с
www.oracle.com/...​odeconventions-150003.pdf
А потом перейти к гайдам от дяди Боба

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

Оно уже лет 10 как deprecated, о чем на сайте оракла предупреждает большой красный баннер.
Мне когда-то нравилось www.javapractices.com

docs.oracle.com/...​6/generic.903/bp/java.htm
Я читал еще это. но здесь больше комплексный подход уже в энтерпрайз контексте, а вот требования к самому синтаксису написания не нашел.

Не требования, практика, оговорился

Попробуй посмотреть порт Accord.net на Java. Функциональный фреймворк по машинному обучению, довольно неплохой код.
github.com/accord-net/java

Базовые правила оформления кода которые там описаны до сих пор актуальны.

Дядя Боб написал тупую макулатуру. Читай нормальные книги по типам данных, читай Бертрана Мейеера хотя бы, Дейкстру.

Я начал с Боба. Просто об очевидном, если в двух словах.

Боб Мартин написал макулатуру, советую читать К. Бек Шаблоны реализации, книги Б. Мейера Почувствуй класс и т.д. Программист — прагматик хорошая книга.

Читай клин код от дядюшки Боба и применяй. И будет тебе счастье.

Його не можливо прочитати простим смертним. Тому тільки в нірвані.

Думаю, де б не дивився, а все одно пара абстрактних фабрик фасадів там буде. Люблять джавісти таке.

1. Google Java Style Guide довольно адекватен
google.github.io/...​styleguide/javaguide.html

2. Effective Java, Joshua Bloch

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

Вони ще постять його в discussion під заголовками на кшталт «100% work! one line!!! Java o(1)!!!»

так обычно в дискашн и есть самый крутой код, потом оттуда выбирают лучшие и публикуют как официально решение.

Засношали спамить своим литкодом инфоцыгане

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

Зашёл — инфоцыгане — к монахам

У явы, по современным меркам, очень корявый дизайн самого языка, и как следствие «правильный или чистый» код — есть комбинация различных компромисов, которые у разных людей разные.
Т.е. «чистый код» одного синьйора запросто может вызвать ужас и негодование другого. (Впомнить те же getter/seter vs public field, etc).

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

как бы, публичные поля по-default-у плохая практика. Если бы синийор доказывал мне это, я бы засомневался в его регалиях

Кто этот дефолт сделал дефолтом?

And who’s going to monitor the monitors of the monitors? ©

ок, сначала мой аргумент, жду вашего.
Публичные поля во многих(но не везде))) ) местах плохая практика, потому что мы можем пробросить туда любое значение. Такой подход очень дешев и прост, но если он используется повсеместно, то:
+ у нас относительно мало кода
— этот самый код нужно очень внимательно читать
— иногда приходится всё же насильно делать валидацию+приведение к типу, если в свойство попало «некорректное, или не совсем корректное» значение
И да, мб мы не поняли друг друга: я имел ввиду, что этот спор некорректен, и ясное дело, что и то, и другое должно использоваться, но в меру. Но если челик с упорством гнёт линию, что нужно делать public поля, то я 100% по другую сторону баррикад

публичные поля по-default-у плохая практика

Нарушение инкапсуляции иногда нужно для векторно-матричных алгоритмов выполняемых на managed коде. Прямой доступ к полю массива в 2.5-3 раза быстрее чем через геттер-сеттер. Если приходится работать с 30+ МПикс изображениями с распознаванием на .NET/Java, то там приходится и не так извращаться.

У вас немного другой пример)) Тут споров быть не может, ибо «надо»

Facepalm.
Как такое можно писать без контекста? А если это HFT-код?
Да даже без таких корнеркейсов. Сам подумай — там где применяются getters/setters — там по сути plain (язык не поворачивается назвать это объектами). struct в терминах C. И форму оно имеет такую только потому что люди привыкли к императивным структуркам и процедуркам, а Java всё ещё не поддерживает value types и объединить два или более примитива ты можешь только с помощью reference type’а.
Иногда задумываешься — а зачем этот весь лишний boilerplate, если по-сути тебе нужно несколько public final полей и единственный конструктор чтоб атомарно установить в них значения.
Да, всё равно приходится либо генерить boilerplate либо пользовать кодоинструментацию(lombok) простихоспади. Хорошо хоть idea это всё скрывает и ты не видишь всего этого ужаса.
Искренне надеюсь что когда-то это совершенно тупое правило уйдет и можно будет выражать в коде для чего именно этот кусок тут. Или таки допилят project Valhalla.

Лучше почитай дядьку боба. Один хрен ты после просмотра мало что поймешь

дядя боб замечательный пример

Those who can, do. Those who can’t, teach.

В любом случае надо разобраться вначале с принципами клин код

Я бы посоветовал читать исходный код самой джавы. Структуры данных, например, утильные пакеты, io, nio и т. д. Там и практики явно лучшие, и код на 100% задокументирован. Без сарказма пишу, если что.

Спасибо. Как то даже не подумал о джава доках в исходниках.

Там код весьма страшный. И акцент явно не на «чистоту», а на перформанс.

А нафиг писать «красивый код» если у него перформанс хуже чем у «некрасивого»?
К примеру, есть те, кто пишет чередующиеся однопоточные map, filter, тд., вместо того чтобы выполнить все за O(N) в цикле for/while.

наверно потому что код нада еще поддерживать будет

И это иногда полезно если не захламлять код всякими .collect(toList()); а отдавать Stream.
Да, и если в итерациях цикла будет происходить что посложнее простой арифметики, а, скажем, сложные преобразования то разница производительности таких решений будет на уровне статистической погрешности.
Кстати, time complexity что у того что у другого решения O(n) даже со сборками в списки так что наезд некорректен.

time complexity что у того что у другого решения O(n)

Я писал не про джавовские стримы.

А нафиг писать «красивый код» если у него перформанс хуже чем у «некрасивого»?

В «классическом» enterprise девелопменте, где требования меняются по дуновению ветра, читаемость/сопровождаемость кода намного важнее. Иначе, он просто начнет работать не правильно после очередной правки, и клиент потеряет много денег.

WUT? Как получилось объединить в одно утверждение Tomcat и performance?

в гугле забанили чтоль?

Дякую. Завжди цікаво почути думку досвідченого розробника, тим більш, який починав кар єру з «Гуглу».

Это сарказм, хамство и сарказм разные вещи немного.

Из-за таких #$%баебов, часто на интересующий вопрос в гугл-поиске, находим ответ в стиле «в гугле забанили чтоль?»

Повбывав бы

на онглицком гугль и все будет ок, а то ищешь причины...

Замінив на «переглянути».

Подписаться на комментарии