Другие языки программирования и технологии
Какое главное отличие хорошего кода от плохого?
Хороший код легко читается и легко масштабируется, а если он еще при этом быстро работает и/или использует минимум необходимых ресурсов - это не хороший, а очень хороший код. Все остальное - не очень хороший код.
Как бы тут не писали некоторые, но хороший код это далеко не только рабочий код. Это неправильная и опасная позиция. Хороший код это в первую очередь лёгкий код для понимания, легко читаемый, с хорошей архитектурой, легко масштабируемый, гибкий. Код, с которым сможет быстро разобраться любой, а не так, чтобы лишь автор кода понимал, что там и как работает и какие побочные эффекты возникают. С таким кодом приятно работать, в нём легко править баги и не насоздаешь при этом кучу новых багов. Да и ошибок будет куда меньше.
Александр Мамаев
"Как бы тут не писали некоторые, но хороший код это далеко не только рабочий код"
а кто так пишет-то? только П П может быть.
а кто так пишет-то? только П П может быть.
У хорошего кода хорошие комменты, хорошие юнит тесты и непонятно кто его написал
Александр Мамаев
комменты, юнит-тесты - ок.
а что значит "непонятно кто его написал"?))) ты джун и без в\о, но тебе надо писать код, как синьор и с МГУ за плечами, чтобы не поняли, что ты джун и без в\о?
а что значит "непонятно кто его написал"?))) ты джун и без в\о, но тебе надо писать код, как синьор и с МГУ за плечами, чтобы не поняли, что ты джун и без в\о?
он прост как автомат калашникова.
не нужно тысяча строк на комментарий ...нужен один "Я делаю это", "Я боюсь ошибки"
и всё вычисления за рамками цикла выносятся из него.
четко комментированные данные - зачем и почему
не нужно тысяча строк на комментарий ...нужен один "Я делаю это", "Я боюсь ошибки"
и всё вычисления за рамками цикла выносятся из него.
четко комментированные данные - зачем и почему
пожалуй такое, что всё делается тщательно.
тщательно изучается используемый инструмент. тщательно изучается принятый стиль кода. учитываются и наработки коллег (взаимодействие с командой, социумом), а не посылаются лесом ради ЧСВ и лени. тщательно обдумывается сам код.
но также тщательно ищутся баги в написанном коде, несмотря на всю его простоту и красоту...
если же допустим синьор заставляет джуна по 3 раза переписывать код ради красоты и простоты, но этот код проверяют только этот синьор и этот джун, то этот синьор руками джуна делает баги в проекте под видом благих намерений по развитию джуна.
тщательно изучается используемый инструмент. тщательно изучается принятый стиль кода. учитываются и наработки коллег (взаимодействие с командой, социумом), а не посылаются лесом ради ЧСВ и лени. тщательно обдумывается сам код.
но также тщательно ищутся баги в написанном коде, несмотря на всю его простоту и красоту...
если же допустим синьор заставляет джуна по 3 раза переписывать код ради красоты и простоты, но этот код проверяют только этот синьор и этот джун, то этот синьор руками джуна делает баги в проекте под видом благих намерений по развитию джуна.
Это субъективные оценки и у каждого они свои.
Если код делает свою работу и не требует внимания то он хороший.
Если код плохо делает свою работу или не работает или много гемороя от него то он плохой
даже в случае если он идеально написан и лучше написать в принципе нельзя он все равно плохой.
Если код делает свою работу и не требует внимания то он хороший.
Если код плохо делает свою работу или не работает или много гемороя от него то он плохой
даже в случае если он идеально написан и лучше написать в принципе нельзя он все равно плохой.
Azim Abd
вот, как ни странно, соглашусь.
чтобы в коде не было багов, надо в коде искать баги. ни простота кода, ни порядок в коде, ни дисциплина в работе не уберут баги.
а если ради порядка и простоты код многократно переписывают из-за неопытности автора, то это и дисциплина со знаком минус.
чтобы в коде не было багов, надо в коде искать баги. ни простота кода, ни порядок в коде, ни дисциплина в работе не уберут баги.
а если ради порядка и простоты код многократно переписывают из-за неопытности автора, то это и дисциплина со знаком минус.
Когда он сразу понятен другому человеку
А не ищешь пол часа нахрена он это написал и что оно делает
А не ищешь пол часа нахрена он это написал и что оно делает
Самодокументируемость.
Если код работает, то он хороший. Даже при учёте велосипедов и костылей.
А если код работает с ошибками, даже без костылей и велосипедов, то такой код - плохой. Если не работает вовсе, то понятно дело
А если код работает с ошибками, даже без костылей и велосипедов, то такой код - плохой. Если не работает вовсе, то понятно дело
Azim Abd
вот, как ни странно, соглашусь.
чтобы в коде не было багов, надо в коде искать баги. ни простота кода, ни порядок в коде, ни дисциплина в работе не уберут баги.
а если ради порядка и простоты код многократно переписывают из-за неопытности автора, то это и дисциплина со знаком минус.
чтобы в коде не было багов, надо в коде искать баги. ни простота кода, ни порядок в коде, ни дисциплина в работе не уберут баги.
а если ради порядка и простоты код многократно переписывают из-за неопытности автора, то это и дисциплина со знаком минус.
Мухаммади Джононов
А если этот код работает, но при этом ужасное качество кода, убогая архитектура, плохая масштабируемость. Или код, который вообще невозможно понять, доработать? Или вообще с антипатернами вроде божественного объекта или божественного метод - всё в одной куче, в которой никто не разберется?
Похожие вопросы
- В чем отличие байт кода от машинного?
- В чем главное отличие С++ от С# ? Только умоляю не пишите, что с# объектно-ориентированный.
- Посоветуйте компилятор (не интерпретатор!) BASIC. Он должен создавать высокоэффективный код, в отличие от Visual Basic.
- Вопрос по основам машинного кода и бинарного кода. Как это работает в своей основе?
- Ассемблерная вставка в С .Странный код. Можете расшифровать?
- как прописать bat код в сайт
- Что для вас "говно код" ?
- как научиться писать хороший код? В смысле я даже не понимаю что такое хороший код. Что такое хороший код?
- ООП это когда данные управляют кодом а функциональное когда код данными?
- Получение опыта в области программирования (архитектура программы, качество кода).
между тем они банально перечеркивают все, что ты перечислил. разработчика они сделают несчастным, и чем больше он шлифовал код ради читаемости-масштабируемости-экономичности, тем несчастнее он будет из-за багов.