Здравствуйте Lloyd, Вы писали:
L>Здравствуйте Zlobec, Вы писали:
Z>>Здравствуйте Lloyd, Вы писали:
L>>>Сабж. Z>>Качетсво измеряем в y.e./строка?
L>Исходя из каких характеристик можно определить, качественный код или нет?
А в каких еденицах будем мерить эти харрактеристики?
Здравствуйте Lloyd, Вы писали:
L>Исходя из каких характеристик можно определить, качественный код или нет?
Если тебе нужно внести в него изменения и ты
1) Легко понял организацию программы
2) Легко понял где что можно поправить, при этом ты ощутил что
автор знал что программы изменяются и сделал так что изменения
вносить легко.
3) Твое изменение не вызвало диких побочных эффектов, потому как
программа написана так что побочные эффекты вносить сложно
(типа private/protected расставлены)
Если для чужого кода все эхто выполняется то
это хороший код, если тебе надо тестировать свой
код то отдае его другому человеку.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Lloyd, Вы писали:
L>>Исходя из каких характеристик можно определить, качественный код или нет?
A>Если тебе нужно внести в него изменения и ты A>1) Легко понял организацию программы
A>2) Легко понял где что можно поправить, при этом ты ощутил что A>автор знал что программы изменяются и сделал так что изменения A>вносить легко.
Гм. Получается что на большистве скриптовых языков хороший код не написать. Правда учитывая малый объем кода — это возможно не актуально.
Здравствуйте Zlobec, Вы писали:
Z>Гм. Получается что на большистве скриптовых языков хороший код не написать. Правда учитывая малый объем кода — это возможно не актуально.
Если ты заметил то "хорошесть кода" это понятие относительное,
т.е. можно написать хороший код для данного языка. Но
здесь perl/python с java/C++ конечно не сравнить т.к. первые
динамически типизированные а вторые статистические.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Zlobec, Вы писали:
Z>>Гм. Получается что на большистве скриптовых языков хороший код не написать. Правда учитывая малый объем кода — это возможно не актуально.
A>Если ты заметил то "хорошесть кода" это понятие относительное, A>т.е. можно написать хороший код для данного языка. Но A>здесь perl/python с java/C++ конечно не сравнить т.к. первые A>динамически типизированные а вторые статистические.
От того как и в какой момент объявляются переменные на хорошесть кода ИМХО не влияет.
А вот является ли понятность кода критерием хорошести?
1. Имеет простую и понятную структуру
2. Нет сложных яхыковых конструкций, без которых можно обойтись (i=i++ + ++i )
3. Имеет достаточно комментариев для понимания логики кода (это относится в основном описанию сложных алгоритмов, особенностей реализации на данном компиляторе/ОС и т.д.)
4. Написан в одном стиле с использованием определенных правил кодирования
5. Спроектирован на простое внесение изменений
6. Не имеет сложных и запутанных взаимосвязей с другими модулями/файлами/классами и т.п.
7. Тщательно протестирован
Здравствуйте Zlobec, Вы писали:
Z>А вот является ли понятность кода критерием хорошести?
Она является побудительным мотивом к обвинению кода в "нехорошести".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Здравствуйте Zlobec, Вы писали:
Z>>А вот является ли понятность кода критерием хорошести?
ГВ>Она является побудительным мотивом к обвинению кода в "нехорошести".
Тогда вопрос исключительно в компетенции .
Здравствуйте Zlobec, Вы писали:
Z>Здравствуйте Геннадий Васильев, Вы писали:
ГВ>>Здравствуйте Zlobec, Вы писали:
Z>>>А вот является ли понятность кода критерием хорошести?
ГВ>>Она является побудительным мотивом к обвинению кода в "нехорошести". Z>Тогда вопрос исключительно в компетенции .
По моему главное это правельное документирование кода.
Если приводиш что-то не совсем понятное, но оно эффективней.
Опиши данную конструкцию в коментарии. Чтоб и ламеру было понятно.
Здравствуйте Vampire, Вы писали:
V>По моему главное это правельное документирование кода. V>Если приводиш что-то не совсем понятное, но оно эффективней. V>Опиши данную конструкцию в коментарии. Чтоб и ламеру было понятно.
На самом деле я много думал о комментариях и документации и пришел к выводу что на сам код вообще не надо писать ни комментарий ни доку. Надо описывать только интерфейсы.
Вот какими соображениями я руководствовался: документация это не самоцель, и даже понятный код это не самоцель. Все что в конце концов нужно это написать функциональность затратив на это минимум времени(притом естественно учитывается и время на поиск багов, и время других людей).
Когда ты комментируешь/документируешь то ты при этом тратишь свое время, но экономишь время другим людям. Т.е. вполне бессмысленно писать документацию на код который никто читать не будет.
Вся проблема в том чтобы правильно выбрать что нужно документировать, а что нет. Очень много людей пользуются твоим классом и поэтому надо писать код на интерфейс. Но очень мало людей суются во внутренности. Никто скорее всего туда не сунется если класс будет работать как надо.
Кроме того большие и непонятные функции обычно свидетельствуют о том что код плохо спроектирован. В хорошем коде функции небольшие и с четко выраженой выполняемой задачей.
Таким образом если тебя не удовлетворяет конкретная функция можно просто переписать ее всю. Что она делает должно быть ясно понятно из комментария перед ней всей, а внутри комментарии не понадобятся т.к. будут выкинуты.
Вообщем идея такая: нужно больше времени уделять проектированию системы и документированию общих идей, а не комментариям на конкрентные фичи языка типа
int i=0; // Создать целую переменную с начальным значением 1while(*i++=*j++); // копирование строки
Так же очень помогает давать осмысленные имена функциям вместо того чтобы писать рядом что они делают
getValueX();
getValueY();
//вместо
qweasd();
// Возвращает значение X
asdzxc();
// Возвращает значение Y
Притом вот в таком варианте когда и функции названы понятно и комментарии рядом есть комментарии вредны т.к. являются визуальным шумом
getValueX();
// Возвращает значение X
getValueY();
// Возвращает значение Y
Иногда бывает что содержимого достаточно простого и понятного класса просто тонет в комментариях
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Притом вот в таком варианте когда и функции названы понятно и комментарии рядом есть комментарии вредны т.к. являются визуальным шумом A>
A>getValueX();
A>// Возвращает значение X
A>getValueY();
A>// Возвращает значение Y
A>
Просто хотел добавить, что такие комментарии являются не только шумом,а к тому же иногда начинают нагло врать. После изменений:
getValueA();
// Возвращает значение X
getValueB();
// Возвращает значение Y
SZ>getValueA();
SZ>// Возвращает значение X
SZ>getValueB();
SZ>// Возвращает значение Y
SZ>
Ну это Вы уже утрируете проблему коментарий типа сложения двух чисел — это 3 класс 1 четверть
Я имел ввиду части кода с ярко выраженной оптимизацией.
Когда все так закручено, что можно пару часов изучать алгоритм.
Вариант с описанием интерфейса хорош для COM и почти никогда не подходит для внутрикорпоративного софта.
Который весит 100 — 200 кило, неизвестно что делает и неизвестно какие изменения придется в нем произвести в будущем.
Здравствуйте Vampire, Вы писали:
V>Вариант с описанием интерфейса хорош для COM и почти никогда не подходит для внутрикорпоративного софта. V>Который весит 100 — 200 кило, неизвестно что делает и неизвестно какие изменения придется в нем произвести в будущем.
Ну да если ты думаешь что в данном случае поможет документация то ты ошибаешься.
Нельзя из г. сделать конфетку, хоть сколько ты ее документируй.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Ну да если ты думаешь что в данном случае поможет документация то ты ошибаешься. A>Нельзя из г. сделать конфетку, хоть сколько ты ее документируй.
Зато можно написать обертку и будет выглядеть вполне пристойно.
Я серьезно.
Я так и борюсь со всеми кривыми activex'ами и т.п.
Да, лишний код. Но зато, когда я смотрю на свой код,
использующий свою же обертку я и через год сразу (обычно
понимаю, чего это я такое наваял.
Здравствуйте KeenTheGreen, Вы писали:
KTG>Да, лишний код. Но зато, когда я смотрю на свой код, KTG>использующий свою же обертку я и через год сразу (обычно KTG>понимаю, чего это я такое наваял.
А я и через месяц не могу вспомнить что наваял
Поэтому код и документирую
Здравствуйте KeenTheGreen, Вы писали:
KTG>Здравствуйте Anatolix, Вы писали:
A>>Ну да если ты думаешь что в данном случае поможет документация то ты ошибаешься. A>>Нельзя из г. сделать конфетку, хоть сколько ты ее документируй. KTG>Зато можно написать обертку и будет выглядеть вполне пристойно. KTG>Я серьезно.
Я в курсе. Можешь почитать мою подпись на эту тему.
Но это совсем не документирование. Таким образом ты как
раз создаешь хороший интерфейс, а старый интерфейс при этом
оказывается деталями реализации. Про что я говорил выше.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
)
коментарий типа сложения двух чисел — это 3 класс 1 четверть 
