Авторы жс боялись, что веб-программисты не осилят лишнюю дюжину концепций, поэтому теперь веб-программисты осваивают лишнюю дюжину диалектов.
08.02.2021, 19:46
Мегатонны кода сокрыты вовеки вечные свидетелями энтерпрайза и джава есть пророк его!
Как выглядело бы решение простой задачки FizzBuzz в энтерпрайзе https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Как выглядело бы решение простой задачки FizzBuzz в энтерпрайзе https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Вижу энтерпрайз - делаю форк
Я конечно плюсовый мимокрокодил который на джаве писал всего пару месяцев, но на кой ляд столько всего для кода который умещается в один метод? Да даже в сраном мейне
в Java принято именовать сущности довольно длинными названиями, как говорил один чувак - если в имени класса меньше пяти слов, то я считаю такой класс полной хуйней и использовать не буду.
ну и кроме того куча всяких разнообразных модификаторов, которые в других языках заменяет синтаксический сахар, либо они опциональны, либо отсуствуют вообще.
то есть там, где в js жизнь уже заканчивается, в жабе и c# она только начинается,
потому что одним только неймспейсом, классом и методом ты отступаешь 12 пробелов от начала строки.
а потом пишешь DefaultFizzBuzzUpperLimitParameter defaultFizzBuzzUpperLimitParameter = new DefaultFizzBuzzUpperLimitParameter(new NumberIsMultipleOfAnotherNumberVerifier());
ну и кроме того куча всяких разнообразных модификаторов, которые в других языках заменяет синтаксический сахар, либо они опциональны, либо отсуствуют вообще.
то есть там, где в js жизнь уже заканчивается, в жабе и c# она только начинается,
потому что одним только неймспейсом, классом и методом ты отступаешь 12 пробелов от начала строки.
а потом пишешь DefaultFizzBuzzUpperLimitParameter defaultFizzBuzzUpperLimitParameter = new DefaultFizzBuzzUpperLimitParameter(new NumberIsMultipleOfAnotherNumberVerifier());
Длинные названия тоже считаются дурным тоном, как и короткие до непонятности. Потому в Java мире ценятся названия и строки кода, которые максимально короткие при условии сохранения читабельности и самодокументируемости кода.
А для длиннострокофобов придумали правила переноса строк, которые поддерживаются на уровне ИДЕ автоматически.
А для длиннострокофобов придумали правила переноса строк, которые поддерживаются на уровне ИДЕ автоматически.
ну, я как сторонний наблюдатель говорю, я от жабы довольно далёк.
в длинных названиях нет ничего плохого, класс может служить только источником метаданных или отражать такое же длинное имя репозитория (почему у репозитория настолько длинное имя - это уже другой вопрос).
в длинных названиях нет ничего плохого, класс может служить только источником метаданных или отражать такое же длинное имя репозитория (почему у репозитория настолько длинное имя - это уже другой вопрос).
Дело привычки и адекватного подхода. Такой пример -- абстрактный конь в вакуме, в большинстве случаев имеем нечто такое "var user = dao.GetUserById(id)", вполне читаемо и накрайняк IDE прекрасно подсветит название класса. Еще избавляет от "масло масляное" как указали коментом выше, и удобней в написании кода (не нужно вспоминать полное имя класса переменно и подключать namespace).
Вообще весь этот сахар не супер необходим, я бы больше хотел видеть единый стиль написания кода хоть с var, хоть без него. В таком случае быстро привыкаешь писать по единому шаблону и не занимаешься "наведение красоты".
Вообще весь этот сахар не супер необходим, я бы больше хотел видеть единый стиль написания кода хоть с var, хоть без него. В таком случае быстро привыкаешь писать по единому шаблону и не занимаешься "наведение красоты".
Не любил в C/C++ auto, пока не перешёл на ФП. Почти все современные языки одновременно с явной изменяемостью (val/var или let/let mut или как-то ещё) отказываются от явных типов (из знакомых мне — Rust, Scala, Kotlin, Swift), прибегая к ним только когда надо явно указать что-то невыводимое вроде «let requests: Result<Box<dyn Iterator<Item = http::request::Request>>, _> = ….collect()?;».
Ну а назначение должно быть понятно из самой функции и названия переменной (благо можно переобъявлять затирающую переменную с тем же названием): «let render = RenderActor::new(device); render.rebuild_queue();», в случае явного указания один раз продублируется RenderActor, который там и так в названии переменной и структуры, а rebuild_queue как был от неявного типа, так и остался. Некоторые языки (вроде Scala) позволяют даже скрывать частично описание типов функций (в т.ч. выходных нерекурсивных), в отличие от того же раста, где свободные замыкания требуют типов. А иногда тип назвать слишком сложно — ради этого в расте выдумали «impl» (нарп.: … ->impl Iterator<Item = u32>, т.к. реальный тип будет двадцатиэтажным с ZipIterator, ChainIterator, ReverseIterator…).
Я стал себя старого (тот, который избегал auto) видеть старпёром.
Ну а назначение должно быть понятно из самой функции и названия переменной (благо можно переобъявлять затирающую переменную с тем же названием): «let render = RenderActor::new(device); render.rebuild_queue();», в случае явного указания один раз продублируется RenderActor, который там и так в названии переменной и структуры, а rebuild_queue как был от неявного типа, так и остался. Некоторые языки (вроде Scala) позволяют даже скрывать частично описание типов функций (в т.ч. выходных нерекурсивных), в отличие от того же раста, где свободные замыкания требуют типов. А иногда тип назвать слишком сложно — ради этого в расте выдумали «impl» (нарп.: … ->impl Iterator<Item = u32>, т.к. реальный тип будет двадцатиэтажным с ZipIterator, ChainIterator, ReverseIterator…).
Я стал себя старого (тот, который избегал auto) видеть старпёром.
Ну это блин от языка зависит. У нас на Swift например тоже есть var и let (что то типо const var). Так вот, в реальных задачах дохрена повторяющихся моментов.
Например ты в 300 раз берешь высоту вьюхи
let height = view.bounds.height
Любой кто работал c UIKit (там определены все эти View с bound и прочее) прекрасно знает что все измерения там это CGFloat, так зачем об этом писать?
С другой стороны у нас есть возможность явно указать тип, возвращаясь к примеру выше это:
let height: CGFloat = view.bounds.height
или
let height = view.bounds.height as CGFloat
И мне нравится эта вариативность! Здорово когда создатели языка не относятся к тебе как к обезьяне за компом, и дать возможность писать в любом стиле.
Например ты в 300 раз берешь высоту вьюхи
let height = view.bounds.height
Любой кто работал c UIKit (там определены все эти View с bound и прочее) прекрасно знает что все измерения там это CGFloat, так зачем об этом писать?
С другой стороны у нас есть возможность явно указать тип, возвращаясь к примеру выше это:
let height: CGFloat = view.bounds.height
или
let height = view.bounds.height as CGFloat
И мне нравится эта вариативность! Здорово когда создатели языка не относятся к тебе как к обезьяне за компом, и дать возможность писать в любом стиле.
А я наоборот предпочитаю, чтобы вариативность без пользы устранять. Слишком много обезьян за компом нанимают, чтобы перепродать подороже... Задалбывает на ревью писать людям, что они хуйню написали в очевидном месте, и что их мега метод уже реализован где-то в ядре языка и можно сократить до пары строк.
О, действительно, все же пишут код в блокноте, а не в IDE, где можно включить inlay hints, если ты уж пишешь код, не понимая, что возвращает тебе DoSomeMethod()
Ненавижу кодерастов, блять, понабрали со stackoverflow, даже не смотрят, что делают и возвращают методы, которые используют...
Ненавижу кодерастов, блять, понабрали со stackoverflow, даже не смотрят, что делают и возвращают методы, которые используют...
за такие названия надо отрывать руки. Такая порнография нихуя ни по одному кодстайлу.
Ибо название должно быть:
говорящим(потому что иначе нахуй оно?)
коротким(потому что через точку порой писать дохуя и сам же заебешься)
без смехуечков и сокращений, если только сокращения не общепринятые в предметной области(какой-нибудь СНИЛС - да, а ММРСДН - нет, ибо хуй его знает что он там значит)
Ну и перенос строк, да.
ну и на реакторе просто традиционно не любят жабу.
Ибо название должно быть:
говорящим(потому что иначе нахуй оно?)
коротким(потому что через точку порой писать дохуя и сам же заебешься)
без смехуечков и сокращений, если только сокращения не общепринятые в предметной области(какой-нибудь СНИЛС - да, а ММРСДН - нет, ибо хуй его знает что он там значит)
Ну и перенос строк, да.
ну и на реакторе просто традиционно не любят жабу.
В гибернейте есть одно совершенно блядское исключение - гибернейт позволяет писать запросы в базу именем метода. Вот там такое порой бывает...
хотя лично я против таких изъебов
хотя лично я против таких изъебов
именование сущностей вообще крайне мало имеет отношения к кодстайлам, и максимум, что об этом упоминается в верхних результатах из гугла, так это Try to keep your class names simpleand descriptive. Use whole words—avoidacronyms and abbreviations (unless the abbre-viation is much more widely used than thelong form, such as URL or HTML). в code convention от Oracle.
стайлгайд от собственно гугла, например, на эту тему вообще не заикается. и правильно.
хотя, если вы там "заебываетесь дохуя писать", то, возможно, у вас эта проблема с длинной имен стоит действительно остро.
а именования в примере вполне себе адекватные (насколько они могут быть такими для FizzBuzz на манер энтерпрайз) - говорящие, в меру короткие, без смехуечков и сокращений. тут проблема в том, что это изначально не должно быть отдельным классом - этот класс это две-три строки и они не должны были подлежать декомпозиции, а не в их длине имен того, что в результате её получилось.
стайлгайд от собственно гугла, например, на эту тему вообще не заикается. и правильно.
хотя, если вы там "заебываетесь дохуя писать", то, возможно, у вас эта проблема с длинной имен стоит действительно остро.
а именования в примере вполне себе адекватные (насколько они могут быть такими для FizzBuzz на манер энтерпрайз) - говорящие, в меру короткие, без смехуечков и сокращений. тут проблема в том, что это изначально не должно быть отдельным классом - этот класс это две-три строки и они не должны были подлежать декомпозиции, а не в их длине имен того, что в результате её получилось.
иде спасает от любой длины, фигня вопрос. Только читать эту лапшу потом немного неприятно, а однострочник распедаливает на пол-страницы.
Что до кодстайла, я обращаюсь скорее к своему опыту, где имена имели предельную длину и ебись как хочешь.
Что до кодстайла, я обращаюсь скорее к своему опыту, где имена имели предельную длину и ебись как хочешь.
Такие названия вполне естественно появляются.
Сначала у тебя есть FizzBuzz. Потом появляется некоторый лимит, он становится BuzzUpperLimit. Потом появляется необходимость его конфигурировать, получается FizzBuzzUpperLimitParameter. Через какое-то время чувак замечает, что параметры часто одни и те же и решает сделать класс DefaultFizzBuzzUpperLimitParameter, чтобы в конструкторе засеттить всё дефолтами и не писать каждый раз одну и ту же портянку с настройками.
Каждый из этих шагов - логичный и понятный. Правило бойскаута "ща я отрефачу всё нахер" рассыпается, сталкиваясь с реальностью "какого хера на задаче оцененную в час ты сидишь второй день"/100500 конфликтов с 547 других разработчиков и невозможность в итоге ничего залить/волшебные слово "Рефлекшн" и "внешняя интеграция".
Сначала у тебя есть FizzBuzz. Потом появляется некоторый лимит, он становится BuzzUpperLimit. Потом появляется необходимость его конфигурировать, получается FizzBuzzUpperLimitParameter. Через какое-то время чувак замечает, что параметры часто одни и те же и решает сделать класс DefaultFizzBuzzUpperLimitParameter, чтобы в конструкторе засеттить всё дефолтами и не писать каждый раз одну и ту же портянку с настройками.
Каждый из этих шагов - логичный и понятный. Правило бойскаута "ща я отрефачу всё нахер" рассыпается, сталкиваясь с реальностью "какого хера на задаче оцененную в час ты сидишь второй день"/100500 конфликтов с 547 других разработчиков и невозможность в итоге ничего залить/волшебные слово "Рефлекшн" и "внешняя интеграция".
ну так не пиши всю историю разработки в название. Согласись, твой дефолтный класс можно обозвать FizzBuzzInitializer и в нем уже конкретные методы, если их несколько, или какой-нибудь getInstanse если всего один. Просто на каждом описанном тобой шаге чувак забил напрягаться над названием и тупо увеличил текст. Понятно, у него полно задач и некогда напрягаться над всякой херней(блин, можно подумать я не в энтерпрайзе работаю), но это нихрена не нормально.
У всех разный кодстайл. Ругать чужой и хвалить свой - просто непрофессионально.
Я щас посмотрел - 120 символов это от края до края. Читать стену такого кода - удовольствие ниже среднего.
В реальной работе нет специальной олимпиады "Запихнуть побольше кода в одну строку", смысл чтобы хорошо читалось. Строки в 120 символов читаются херово. Терминалы в 80 символов изначально сделали не дебилы которые не могли сделать его шире - были, так сказать, определенные причины
Я щас посмотрел - 120 символов это от края до края. Читать стену такого кода - удовольствие ниже среднего.
В реальной работе нет специальной олимпиады "Запихнуть побольше кода в одну строку", смысл чтобы хорошо читалось. Строки в 120 символов читаются херово. Терминалы в 80 символов изначально сделали не дебилы которые не могли сделать его шире - были, так сказать, определенные причины
А я не ругаю. Пользуйся на здоровье. Но наука "эргономика" с тобой не согласна: http://webtypography.net/2.1.2
кодить в без ide джаву...
Не, я понимаю, что дело личных пристрастий и мощностей машины, но лично мне как-то дико такое...
Не, я понимаю, что дело личных пристрастий и мощностей машины, но лично мне как-то дико такое...
Для таких надо checkstyle и sonar на каждій коммит запускать, чтобы за каждый пробел и отступ пропущенный было больно.
Чтобы написать коммент, необходимо залогиниться
