Красивый код

Привет всем! С детства (с 14 лет) программирую на С++ (уже где-то 4-4.5 года).
Код пишу так, как это удобно мне. Дроблю на классы таким же макаром... Всегда работал один. Изредка созваниваюсь со знакомыми, чтобы обсудить те или иные тонкости в проектировании чего-либо.
И иногда мне кажется, что мой код отвратителен: я либо пишу всё в куче, либо чересчур сложную, неоправданную систему проектирую... Как-то мне от этого не по себе.

Собственно: я хочу научиться писать красивый и понятный код. Такой, который воспринимался бы на одном дыхании. Помогите пожалуйста советами...

P.S.: не смейтесь please... Да, 4 года программирую, но ещё многого не знаю..

Классическое правило: Make It Work, Make It Beautiful (Right), Make It Fast
Первым делом чтоб работало
Вторым делом чтоб красиво выглядело
Третьим делом (или никогда) оптимизация

Совет: программируй больше и чаще. На первые программы у всех программистов нельзя смотреть без содрогания, они ужасны, но они РАБОТАЛИ. Тогда, в своё время, в нашей молодости, мы смогли сделать какие-то программы, которые сейчас мы, программисты, вспоминаем с удовольствием.

>Собственно: я хочу научиться писать красивый и понятный код. Такой, который воспринимался бы на одном дыхании. Помогите пожалуйста советами...
Лучше старайся писать рабочий код, а то чрезмерная педантичность до добра не доведет, опустишься до уровня форумного тролля вроде меня и уже ничего не сможешь исправить.
Короче сначала рабочий код, а когда опыта наберешься, тогда будешь писать красивый код.

kvakvs
ну... У меня довольно много программ готовых на винте валяются. И довольно страшно смотреть на код :(  Ну а писать в таком же духе... Ну... Неправильно, что ли. Я хочу стать профессионалом своего дела, поэтому мне интересно кто каких правил придерживается : )

Спасибо за три правила. Довольно просты))
А что делать, если я знаю как тот или иной класс будет работать, какие задачи решать, но я не знаю как его назвать? Такое часто бывало

nes
> Лучше старайся писать рабочий код, а то чрезмерная педантичность до добра не
> доведет, опустишься до уровня форумного тролля вроде меня и уже ничего не
> сможешь исправить.
> Короче сначала рабочий код, а когда опыта наберешься, тогда будешь писать
> красивый код.
Хм... Ок. А по поводу оптимизации... Слышал, что код можно прогонять по каким-то тестам... Что те или иные тесты вообще делают?

Laynos
> А что делать, если я знаю как тот или иной класс будет работать, какие задачи
> решать, но я не знаю как его назвать? Такое часто бывало
Именование -- классическая проблема у программистов, никогда не знаешь как назвать и потом кажется, что назвал неправильно. Называй как кажется оптимальным сейчас, а потом переименуешь. Это решается средствами рефакторинга в IDE (переименовать класс в современной IDE дело двух нажатий клавиш).

И для этого обычно используются такое правило: Класс должен делать одно и делать это хорошо.
Когда класс (или модуль) делает одну вещь, то и назвать его легко.

kvakvs
nes
И ещё вот что хотел спросить... А есть ли какие-то общепринятые наименования всяких фич? Где можно почитать? (а по поводу всяких графических технологий?)
Часто придумываю что-то своё, потом довольно сложно объяснить другим что это такое и т.п.

вот например, я всегда думал, что использовать имена, начинающиеся с р, для указателей - красиво. А потом прочитал, что так уже лет десять не именуют. И что мне делать?

Laynos
>Хм... Ок. А по поводу оптимизации... Слышал, что код можно прогонять по каким-то тестам... Что те или иные тесты вообще делают?
Оптимизация это уже после того как научился писать работающий и красивый код, пока на нее даже не стоит заострять внимание.
Оптимизировать нужно если имеешь дело со сложным ПО и оно работает не так хорошо как хотелось бы,
нет смысла что-то оптимизировать, ради выигрыша в экономии пары МБ ОЗУ или нескольких тактов ЦПУ.

Laynos
>И ещё вот что хотел спросить... А есть ли какие-то общепринятые наименования всяких фич? Где можно почитать? (а по поводу всяких графических технологий?)
>Часто придумываю что-то своё, потом довольно сложно объяснить другим что это такое и т.п.
Сам велосипедил по черному, но советую почитать про паттерны проектирования, если есть желание и время.

Laynos
> Спасибо за три правила. Довольно просты))
Добавляю ещё пару правил, которые помогут в будущем.
- пиши (имеется ввиду оформление) код не для себя, а для других. Через 2-3 месяца, при возврате к старых исходным кодам проще будет разобраться. Отсюда вытекает 2 правило.
- комментируй код. Особенно (на твой взгляд)  в критических местах. Проще будет вспоминать работу алгоритмов (недавно с такой бедой столкнулся. Написал код, полгода назад, доку надо было написать. День вспоминал, как он работает).
- документируй код (не обязательно, но очень полезно для себя же). Я у себя юзаю doxygen. На выхлопе сразу можно получить .chm, .pdf файл с описанием, например, твоего класса. Удобно, если работаешь в команде (изменил класс - разослал pdf, lib, dll).
- выработай свои стиль оформления кода (ну тут товарищей нет, правда тоже есть свои правила). Т.е. не пиши код в разных проектах в разных стилях.

Если книги и  статьи на эту тему
http://habrahabr.ru/post/172091/

Laynos
> Всегда работал один
В моей карьере качественные скачки в программировали были после работы в команде. Причём разные коллективы позволяют по-новому взглянуть на некоторые вещи, перенять всё лучшее. Я считаю, что поработать в команде необходимо, причём, чем выше уровень коллег по сравнению с вашим, тем, естественно лучше, но тут уж как повезёт.

Anton Riot
> В моей карьере качественные скачки в программировали были после работы в
> команде. Причём разные коллективы позволяют по-новому взглянуть на некоторые
> вещи, перенять всё лучшее. Я считаю, что поработать в команде необходимо,
> причём, чем выше уровень коллег по сравнению с вашим, тем, естественно лучше,
> но тут уж как повезёт.
У меня был один шанс такой. Пригласили присоединиться к разработке ММО, дали доступ к коду... Миллион строк кода, никаких объяснений: "ДЕЛАЙ". Пришлось вскоре уйти, ибо командной работы не было...
asvp
> Если книги и статьи на эту тему
> http://habrahabr.ru/post/172091/
Сокровище, а не статья!

Laynos
> И ещё вот что хотел спросить... А есть ли какие-то общепринятые наименования
> всяких фич? Где можно почитать? (а по поводу всяких графических технологий?)
> Часто придумываю что-то своё, потом довольно сложно объяснить другим что это
> такое и т.п.
Думаю стоит почитать чужой код и набраться всяких умных слов, но не запоминать и повторять всё буквально, все эти менеджеры фабрик и синглтоны (ужасно), а сделать собственные выводы и выбрать свою терминологию почти похожую на общепринятую. Всё равно через 5-10 лет читая свой сегодняшний код будешь не согласен со всеми именами всех переменных (поменялись убеждения, решил называть более длинными именами, поменял такой_стиль на такойСтиль или m_такой_стиль, и так далее).

Главное правило здесь — человек увидевший твоё название класса в первый раз (или ты сам, увидевший свой код через пару недель, когда всё подзабылось), должен сразу разобраться что это название означает. Можно даже сказать: explain me like i'm five (расскажи другому человеку про свой код так просто, будто ему пять лет).

static_cast
> вот например, я всегда думал, что использовать имена, начинающиеся с р, для
> указателей - красиво. А потом прочитал, что так уже лет десять не именуют. И
> что мне делать?
Именовали по той причине, что видеть тип в имени переменной было удобно, а IDE раньше не очень хорошо умели вычислять и показывать типы и переходить к определениям переменных. Сейчас это решено и IDE просто замечательно разбирают код программы, собирают промежуточные результаты компиляции и знают о твоей программе намного больше, чем ты сам. Сейчас навёл мышь или нажал "перейти к определению" и вопрос, что за тип, закрыт.

Laynos
> Сокровище, а не статья!
Да сколь угодно, читай.
http://www.proklondike.com/books/cpp/allen_golub_rules.html
http://rsdn.ru/res/book/cpp/effective_cpp2006.xml
http://habrahabr.ru/post/194752/
http://wmate.ru/ebooks/book641.html