раскрыть ветку (60)
Имеется в виду "проводить рефакторинг", то есть переделывать код из состояния "написан быстро и тупо чтобы работало" в состояние "какой же красивый и удобный код".
раскрыть ветку (40)
раскрыть ветку (28)
Почему то в моём случае это приводит к уменьшению читабельности. Всё начинает куда-то обращаться и хер проссышь где концы и как их сопоставлять(
раскрыть ветку (24)
Значит еще предстоит понять дзен в красивом коде. У меня тоже такое когда-то было, теперь уже понимаю лучше, как правильно проводить рефакторинг.
раскрыть ветку (7)
раскрыть ветку (6)
Ебать) тогда то, что у вас бывает идея "что надо иногда переписывать, чтоб стало красивее" - уже охуительно)
раскрыть ветку (2)
раскрыть ветку (1)
Заходит дизайнер в ветку прогеров:
...создать класс для констант..
Алиса, как выглядит константа школьник.
(да, не Окей Гугл, а Алиса))
...создать класс для констант..
Алиса, как выглядит константа школьник.
(да, не Окей Гугл, а Алиса))
Ну тут такое, если вы делаете "магию"(ака не само-очевидный код, назначение которого не сразу понятно из основного функционала приводимой леусемы), то стоит активно добавлять комментарии, а если вы используете тулзы для инлайн документации, то и туда добавлять хотя бы краткое описание логики местной "магии".
А в идеале архитектура вашего приложения не должна позволять "магии" становится более эффективной в любой из решаемых подзадач, в реальности она должна просто минимизировать то насколько "магия" эффективна по сравнению с вписывающемся в архитектуру решением, при этом не сделав саму архитектуру черезмерно сложной. Такая скиллуха обычно приходит с опытом(ака просто глубокое понимание задачи, методологии ее выполнения, и существующих решений, что помогут сконструировать систему), не особо хорошо экстраполируется на смежные задачи, и требует работы на этапе проектирования.
раскрыть ветку (10)
В идеале все функции должны говорить о своем предназначении своим названием. Никаких сокращений в наименованиях функций, никаких транслитов и прочих попыток локализации.
Ну и содержимое функции не должно быть мультитулом. Одно действие - одна функция. Экономить на байтах в названии и количестве функций, значит изначально родить дремучий легаси, который ни кто, включая роженника, не сможет поддерживать уже через месяц
Ну и содержимое функции не должно быть мультитулом. Одно действие - одна функция. Экономить на байтах в названии и количестве функций, значит изначально родить дремучий легаси, который ни кто, включая роженника, не сможет поддерживать уже через месяц
раскрыть ветку (9)
Не соглашусь по поводу сокращений. Часто это доводят до абсурда.
вот есть обозначения времени и их сокращения.
milliseconds - ms
microseconds - us
и т.д.
разница в колве букв между полным именем и сокращением - огромная.
Также, с временем часто проводят математические манипуляции.
И если использовать полное именование, то получается пиздец большие и нечитабельные функции даже при простом выражении.
Типа
DateTime.now().toMillisecondsSinceEpoch() / millisecondsPerSecond + lifetimeInSeconds.
А могло бы быть
DateTime.now().toMsSE() / msPerSec + lifetimeInSec.
И это только 2 мат. Операции. А прикиньте какой нечитабельный пиздец происходит при работае с TimeSeries, если не использовать сокращения?
Это не только здесь. Есть ещё куча моментов, которые по непонятным причинам полностью пишут, хотя они капец капец как распространены и хер знает кто может их трактовать неправильно.
Repo - Repository
DB - Database
Так можно и HTML начать полностью расшифровывать. Нельзя же сокращать.
вот есть обозначения времени и их сокращения.
milliseconds - ms
microseconds - us
и т.д.
разница в колве букв между полным именем и сокращением - огромная.
Также, с временем часто проводят математические манипуляции.
И если использовать полное именование, то получается пиздец большие и нечитабельные функции даже при простом выражении.
Типа
DateTime.now().toMillisecondsSinceEpoch() / millisecondsPerSecond + lifetimeInSeconds.
А могло бы быть
DateTime.now().toMsSE() / msPerSec + lifetimeInSec.
И это только 2 мат. Операции. А прикиньте какой нечитабельный пиздец происходит при работае с TimeSeries, если не использовать сокращения?
Это не только здесь. Есть ещё куча моментов, которые по непонятным причинам полностью пишут, хотя они капец капец как распространены и хер знает кто может их трактовать неправильно.
Repo - Repository
DB - Database
Так можно и HTML начать полностью расшифровывать. Нельзя же сокращать.
раскрыть ветку (7)
Если что, то Ms - мегасекунды, а не миллисекунды (ms). Что значит SE догадаться в принципе невозможно.
Общеизвестные сокращения допускаются в названии. В большинстве конвенций это не является ошибкой. Но здесь не тот случай.
Я бы изменял не название методов, а написание изначальной формулы.
раскрыть ветку (3)
Ms здесь обозначено только в силу camel case. Есть, конечно, рекомендации такие сокращения писать с больших буква, как IO, HTML, и т.д., но в данном случае, имхо, Ms приемлимо.
Каждый, кто сталкивается с временем, знает про UTC, знает выражение "Since Epoch" (он же SE), ну и всякие сокращения ms, us. Я, встретив схожее в одной из библиотек, сразу понял что к чему, т.к. ранее сталкивался с этим.
А если прогер не изучил предметную область, но сразу лезет что-то ковырять, то тут уже в другом беда.
раскрыть ветку (2)
Как отличить ms (мили) от Ms (мега), если используется camel case? Ответ: никак. Вывод: сокращение неуместно.
То, каким образом и как пишется (акронимы - большими или маленькими) определяется принятой в команде конвенцией. Это пустое обсуждение, поскольку мы, вполне вероятно, используем разные конвенции.
раскрыть ветку (1)
В контексте времени мегасекунды не используются. Так можно сказать "А мож Ms это MicroSoft". Не доводим до абсурда.
Как минимум, надо вынести константу и не вычислять время в формуле. Тогда всё читается:
milesecondsSinceEpoch = DateTime.now().toMillisecondsSinceEpoch()
MILESECONDS_PER_SECOND = 1000
milesecondsSinceEpoch / MILESECONDS_PER_SECOND + lifetimeInSeconds
А если формула разрослась, то её надо делить на несколько формул.
раскрыть ветку (2)
Не люблю в этих случаях плодить переменные, потому что они немного сбивают с толка. Ниже пример.
Вообще, я написал формулу для вычисления "exp"(expiration) строки для JWT. и выражение нижеDateTime.now().toMillisecondsSinceEpoch() / millisecondsPerSecond + lifetimeInSeconds.
должно присваиваться переменной с наименованием типа "expiration".
Но плодение "промежуточных" переменных вызывает головную боль как их назвать то грамотно.
вот в данном контексте разве логично будет переменную назвать как ниже?milesecondsSinceEpoch = DateTime.now().toMillisecondsSinceEpoch()
И в конечной формуле это превратится в
expiration = milesecondsSinceEpoch / MILESECONDS_PER_SECOND + lifetimeInSeconds.
Для меня переменная сразу должна сказать, нафиг она вообще нужна. Переменная
milesecondsSinceEpoch
ну как то вообще ни о чём. Что за миллисекунды с эпохи? Зачем они нужны? И на что конкретно они указывают? Для меня это как назвать переменную "data". Ну очень полезно. Корректнее тогда уж
currentDateTimeInMillisecondsSinceEpoch
но не легче тогда уж просто написать
DateTime.now().toMillisecondsSinceEpoch()
раскрыть ветку (1)
Как называть переменные лучше уточнить в правилах проекта, в котором вы этот код оставите. Если их нет, то вынести на обсуждение и синхронизировать codestyle.
Иначе, может потом оказаться, что команда не поспевает за вашей гениальностью.
Если топить за "правильный" код, то можно посмотреть clean code, например, или кого-то из оппозиционеров:
https://readlearncode.com/code-and-stuff/clean-code-variable...
P. S.
Я не знаю, какой вы язык используете, но полагаю, что для JWT там есть хелперы с обновлением в секундах или что-то подобное
JWT_LIFETIME_SECONDS=200
Calendar tokenExpirationDate = Calendar.getInstance();
tokenExpirationDate.add(Calendar.SECOND, JWT_LIFETIME_SECONDS);
СВОБРЮЛ, СВРЕГЮЛ, СВНАЛУЧ... Это из базы ФНС - сведения об образовании юридического лица, сведения о регистрации юридического лица, сведения о постановке на налоговый учёт...
Так делать не надо. Но хотя бы гуглится, и на том спасибо.
Так делать не надо. Но хотя бы гуглится, и на том спасибо.
Деды ебашили одну функцию main и она работает как часы до сих пор ещё с 60-х
А нынче 100500 абстракций-хуякций и при этом ниче не работает! Чем код лучше, тем хуже - запомни это, сынок!
раскрыть ветку (3)
раскрыть ветку (2)
Ну даа, инерциальная система управления ядерной ракетой, конечно, проще чем приложение для доставки пиццы например
раскрыть ветку (1)
Сложно сказать, а система управления выдерживает нагрузки в тысячи запросов в единицу времени и успевает их обрабатывать и реализовывать не захлебнувшись? А вообще спор ни о чем, если бы бизнесу не нужно было приложение для пиццы "уже вчера" а давали бы на это лет 10 то и писали бы себе без абстракций хоть на ассемблере, но увы время дороже всего на этом свете)
Всем спасибо за ответы . Товарищи , я далек от программирования , так один раз Винду обновил и Линукс поставил для домашнего пользования.
Английский язык не знаю вообще , родители переезжали и я менял пару школ и учил французский и немецкий ,ну как учил от дождя прятался .
Английский язык не знаю вообще , родители переезжали и я менял пару школ и учил французский и немецкий ,ну как учил от дождя прятался .
раскрыть ветку (1)
раскрыть ветку (1)
Требования бизнеса склонны меняться со временем.
Упреждая вопрос: нет, бизнес сразу крупным построить практически невозможно)
В большинстве случаев, которые я видел, рефакторинг был эвфемизмом для имитации бурной деятельности, призванной объяснить проеб сроков по проекту.
раскрыть ветку (3)
раскрыть ветку (2)
раскрыть ветку (1)
Ну не, это нормальная просьба тимлида, скрам-мастера или кого угодно. С применением профессионального жаргона.
Выше же непонимание процесса и обесценивание работы людей.
Выше же непонимание процесса и обесценивание работы людей.
ещё комментарии
раскрыть ветку (9)
раскрыть ветку (6)
раскрыть ветку (5)
раскрыть ветку (4)
раскрыть ветку (2)
Хоспади, неужели рядом с каждой жирной шуткой надо рядом постить Леонарда с плакатом "Sarcasm"...
раскрыть ветку (1)
ещё комментарии
IT-юмор
7K поста53.2K подписчика
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору