Короче говоря. Я заметил, что здесь тусуется большое количество начинающих программистов. Поэтому хочу дать добрые, дельные, 100%-верные советы:

1. Хороший программист должен быть самостоятельным. Google, wikipedia, хэндбуки, книги, мануалы, комментарии в исходниках - к вашим услугам. Самому разобраться в проблеме и заглянуть чуть дальше - во много раз эффективней, чем получить быстрый рецепт. Пока вы питаетесь быстрыми рецептами, ваша образованность не растет, а резюме не дорожает.

2. Хороший программист должен быть быстрым. Вы можете долго думать над алгоритмом, но придумав, вы должны уметь быстро записать его на любом языке программирования. Почему я говорю "на любом"? Потому что сегодня в мире есть куча софта, который так или иначе использует туеву хучу языков и фреймворков. Сейчас очень редко бывает так, чтобы вы писали, скажем, только на Джаве и ни о чем не беспокоились.

3. Хороший программист должен уметь читать:
1) По-английски. Я ненавижу жалостливые заявления типа "книг о XYZ по-русски почти нет". Зачастую переводы неполны, неграмотны и могут содержать устаревшие сведения. Не умеешь читать по-английски - иди учи.
2) По-любому: уметь вчитываться и понимать написанное, а не пропускать куски абзацев, как делают некоторые.

4. Хороший программист должен уметь писать, как по-русски, так и по-английски.
Во-первых, для того, чтобы задавать вопросы. Сформулированный письменно вопрос сразу дает половину ответа и _значительно_ помогает помощнику найти вторую половину.
Во-вторых, чтобы писать грамотный код. Английский язык я не решусь называть "международным", но в IT-сфере это единственно возможный язык общения.

Золотое правило: забудьте о транслите и русскоязычных комментариях, когда пишете код! Называть переменную kolichestvo_iteraciy - это насрать читателю в душу. То же относится и к отладочному выводу. Не знаете как пишется то или иное слово по-английски? Поищите в google codesearch варианты, или возьмите словарь multitran.

5. Хороший программист знает, что "программистов" не бывает. Бывают инженеры, занимающиеся решением конкретной задачи. А программирование - всего лишь одно из средств её решения (и не всегда самое важное).

(это уже висело на стене, теперь - здесь)

за 5-е в особенности респект

А че-то БК напомнило -))))))

1. Первое правило бойцовского клуба - нет говорить о бойцовском клубе...

Бк форева, 3 года жизни ему отдал

Порадовало золотое правило. Огромное кол-во окружающих меня людей пишут именно так. Приятно узнать, что при взгляде на такой код тошнит не только меня.

огромное кол-во? я с таким сталкивался последний раз в прогах на первом курсе.. студенты так еще пишут.. но чтобы программисты? расстрелять! )

Практически третий курс. Явление отмирает, однако имеет место быть.
Меня еще подташнивает. 8)
Просто некоторые патологически не учатся.

Некоторых патологически не отчисляют (это не только про программистов).

к первому.. =)
во время очередных поисков нужного мана натнулся на сайт http://www.faqs.org/faqs/
с огромным количеством разного рода полезной писанины
возможно, кому и пригодится.. =)

У... ребята да вы где-то на небесах учитесь... Я на 4м - в группе 3 человека код хоть как-то оформляют.

По поводу 2."Хороший программист должен быть быстрым"
Быстрым - это как? В свое время, на первом курсе, я был офигительно быстрым. 2000 строк на С++ за день - лехко. Потом два дня на отладку первых 500 строк. Потом пол-дня на осознание того факта, что выбранная модель не позволит реализовать задачу даже на 50%. Потом 1 секунда на Ctrl+a,delete. Потом еще день на написание еще одной кучи хаков и багов в соответствии с лучшими анти-паттернами программирования. И так далее. "Вы должны быстро записать алгоритм на любом языке программирования" ...и заслужить персональную "доску почета" у сопровождающих программистов. Олег, из вашего профиля цитата: "Plans are worthless, but planning is everything". Очень верная цитата. Придуманный алгоритм - тот самый план, он никогда не соответствует действительности. Потому что при его разработке программист обычно сам еще толком не знает с чем придется столкнуться. Да и термин "алгоритм" звучит здесь как-то странно. Что такое алгоритм? Алгоритм сортировки "пузырьком" и бинарного поиска? В современных условиях программист почти никогда не придумывает алгоритмы, они давно уже придуманы, надо просто их знать. Планирование идет на уровне моделей. А модель - это абстракция. А абстракция всегда чего-то не учитывает. Поэтому "записать быстро" ведет к самым мерзким ошибкам - ошибкам дизайна. Исправляются ошибки дизайна вышеописанным способом - ctrl+a,delete.
Пункт 5 - это скорее религиозная догма, а не совет. На эту тему можно спорить бесконечно. Имхо, для программиста-кристалльщика, программирующего PICи, это может быть и верно. Для программиста, занятого разработкой компиляторов, сидящего на самой верхотуре мат. логики и теории алгоритмов, это смешно - задач инженерного калибра там просто нет.

Алгоритм понятие пошире сортировки будет. И к моделям имеет непосредственное отношение.

"Придуманный алгоритм - тот самый план, он никогда не соответствует действительности."
Именно поэтому нужно тщательнее думать над алгоритмом, а имплементировать быстро, чтобы сразу оценить его соответствие реальности.

Понятие "инженер" (как и "дизайнер") шире, чем вы думаете.

Владимир прав, задача - модель - язык - алгоритм должны соответствовать друг другу. Писать систему документооборота на асме или прошику микроконтроллера на яве затеи явно бредовые. И бессмысленно пытаться овладеть сразу всеми областями.
Лично моё мнение надо осознавать некоторую парадигму программирования (какую это уж дело вкуса) и знать 1-2 языка её реализующую. Знание дополнительных вещей типа SQL или HTML вещи фоновые, тем более, что в крупных фирмах всегда есть спецы именно по ним.

со всем согласен, кроме одного - чем рускоязычные комментарии не угодили?

освежило в памяти один рассказик - "История Мела, настоящего программиста"

Поработайте программистом лет 12..15. Вас все эти технологии так заебут, что вы посчитаете фразу "бессмысленно пытаться овладеть сразу всеми областями" незаконченной. Главное -- смотреть дальше любых технологий, т.к. они приходят и уходят, а вы - стареете. Нужно подумать о жизни вокруг тоже.

Русскоязычные комментарии заебали. Когда читаешь доку на английском, пишешь на рельсах, которые все-из-себя как английский язык, то думаешь тоже на английском. И тут натыкаешься на _иностранный язык_ -- русский. Русский классный язык, но вне кода и тестов. В описухах, рекламе, иных доках, разговорах, докладах. Но не в коде - там свой мир, свои правила.

(буквы составлены по материалам обсуждения с матерым сотрудником студии лебедева)

Не люблю писать русскоязычные комментарии исключительно потому, что нужно переключать раскладку клавиатуры...

Лично мне русскоязычные комментарии практически не попадаются.
Зато попадаются немецкоязычные, итальянскоязычные и испанскоязычные :)
Тоже то еще удовольствие, поверьте.

комментарии это еще ничего, а вот имена классов, методов и прочего (там где язык\платформа позволяют utf идентификаторы) это зло! как-то раз нам принесли код на испанском.... fucking shit все что можно было сказать....

А мне иногда на английском такие комментарии попадаются, что лучше бы уж на русском их написали :)

Я как-то работать устраивался... на второй день, взглянув на код, я капитулировал поджав хвост )) все названия транслитом или вида procedure_1, procedure_2 =)) Комменты на русском, архитектура бездарная.
Причем дядьки, работающие там, на первый взгляд вполне серьезные.

Да, названия идентификаторов, написанных транслитом, страшно бесят.

Страшные вы люди...

Тут все с 6 лет программят, да? Я один с 15? =)

Я с 13, каюсь.

Олег,у меня вопрос по "Хороший программист должен быть быстрым". Ты писал, что пользуешься Ruby и ТDD. Вот действително, скажи как у тебя получается писать без фундаментального проектирования, паттернов и прочего. Или я ошибаюсь? Насколько я понимаю с помощью TDD можно хорошо написать какой-нибудь метод, но как тут удается строить общую красивую, эффективную архитектуру?
И еще по поводу самостоятельности. Часто замечал, что общение с опытными прогарммистами идет очень на пользу, потому как маны, документация и прочее, это все теория, человек же с большим опытом может подсказать то, к чему бы ты сам шел очень долго.

Пока ты напишешь спецификации/тесты на код, ты архитектуру продумаешь и не раз. Потому что ты уже используешь код и смотришь, чего не хватает, чего нужно добавить, что убрать, на что заложиться в будущем.
А на счет самостоятельности: просто не нужно, как некоторые сидеть и ждать, пока гуру ответит на вопрос и самому ничего не делать.
Пытаешься сам, ищешь сам, если нужно быстро, спрашиваешь у гуру и ищешь сам, гуру ответил - в голове запомнил, что в эту тему нужно углубиться, иначе опять к гуру придется лезть.
Конечно.. общаться с гуру можно, но вот только не на RTFM-ные темы, а на идейные/философские - в-общем на те, где действительно без опыта не обойтись.

"Пока ты напишешь спецификации/тесты на код, ты архитектуру продумаешь и не раз" - что-то я в это не верю, попахивает стихийным программированием. Поясни, если не влом, на какои-нибудь примере как спроектировать софт с помощью TDD.

"Конечно.. общаться с гуру можно, но вот только не на RTFM-ные темы, а на идейные/философские - в-общем на те, где действительно без опыта не обойтись." - полностью согласен.

э.. кто тебе сказал, что никто ничего не планирует?
планируем.. только тратим на это меньше времени и постоянно изменяемся под требования заказчика.. (я это понимаю, как Agile)

Денис, уточняю: в TDD очень тяжело описывать дизайн, это верно. Поэтому мы используем BDD (RSpec), в котором этот самый дизайн и описываем.

"Поясни, если не влом, на какои-нибудь примере как спроектировать софт с помощью TDD."

Почитай про БДД на rspec.rubyforge.org

//Про отличия BDD от TDD читай на novemberain.com

Пасип, буду разбираться.

Насчет общения с гуру. За N минут общения с гуру ты не узнаешь столько, сколько сам прочтешь в специально написанной книге. Если в книгах твой вопрос не освещен — тогда другое дело.

Ну понятное дело, что я у гуру не спрашиваю RTFM-е вопросы.

Re: "В современных условиях программист почти никогда не придумывает алгоритмы, они давно уже придуманы, надо просто их знать." - акуеть... дайте двэ...

вот меня, не знаю почему,(уж извените за прямолинейность изложения мысли) это всегда бесило...когда люди говорят фразы типа зачем "изобретать велосипед..." подругому это называется "Ctrl+C. Ctrl+V"...далеко не все придумано далеко все не понято..., вот многие думают что придумывать офигенно быстрые алгоритмы это дело супер-мега-умных людей...по мне так это далеко не так, даже я в этом просто уверен...есть задачи такого класса что чем меньше знаешь тем легче решить, однако кто мешает отойти от знаний в других задачах? все привыкли прсто куда нипоподя втыкать только математическую, жесткую абстракцию...надо просто стараться импровизировать и никогда не смотреть на проблему с одной стороны...

зачем это надо? придумывать что-то свое для меня просто интересно...

даже если тот алгоритм который придумали вы не самый быстрый но он ВАШ, сразу результата конечно не будет, нужно время... а пока время есть я бы рекомендовал не тратить его на доскональное изучение алгоритмов и технологий(их на самом деле не так много как тут уже говорили, их намного меньше чем математической теории), а на формирование в вас собственной модели мышления, и способности смотреть на вещи с разных сторон. Я не говорю что изучать не ваши алгоритмы или технологии вообще не нужно, это даже полезно, но нужно находить некий компромис между количеством одного и другого...

где то вы никогда не сможете стать первыми...
где то только вы сможете стать первыми...

ВотЪ такое вот ИМХО...

Про русские комментарии:
А если пишешь на асме, описание контроллера уже знаешь наизусть... и единственный документ который читаешь во время разработки: "Техническое задание", написанное что интересно на русском, то ИМХО самый удобный тип комментариев - это комментирование кода цитатами из ТЗ. И потом намного проще объяснять себе и другим почему устройство работает так. А так же, сверяясь с ТЗ, на много проще вспоминать почему ты здесь написал именно такой хитрозакрученный алгоритм.

Кстати, Дэн, какие есть средства автоматической проверки кода для контроллеров? Типа юнит- и функциональных тестов, я имею в виду. Чтобы описать требуемое поведение в виде кода и пропускать по нему твою программу для проверки на соответствие ТЗ.

Честно говоря ничего про такое не знаю. Во всяком случае для pic-ов.
Для pic-ов в принципе конечно есть программный симулятор контроллера, но проблема в том, что часто, чтобы проверить корректность работы программы нужно проверять не только полностью всё устройство, содержащее микроконтроллер, но также надо подключать еще другие пару-тройку устройств.
А для автоматизации либо пишется программа симулятор на компе(если устройство работает через RS232), либо делается некий стенд автоматизированной проверки. Но стенд это тоже устройство.

Распечатал и повесил на стенку чтоб не забывать заповеди... =)

Язык зависит от место в котором работаешь. Одно дело если разработкой занимаются нанятые на неопредленной срок сотридники из одной страны, потом доработка где-то в другой итд итп. Здесь нужен конечно же английский.
А вот если работаешь в компании, да еще и в русской - выбор есть.

А вообще писать код нужно так, чтобы он в комментах не нуждался.

и по поводу - хороший программист должен уметь писать на любом языке - бред. Быстрый программист - бред в квадрате.

Эт хорошо подмечено, насчёт кода, чтоб в каментах не нуждался.
Про любой язык уже каментил, тож согласен =))

Роман, "писать так, чтоб код в комментах не нуждался" — это хорошо и правильно, но не нужно доводить до крайностей. Во-первых, код — не греческая статуя, все время развивается. Поэтому комментарии помогают понять, почему та или иная часть должна (или может) быть переписана. Во-вторых, бывают довольно хитрые алгоритмы, и как бы хорошо ни были бы написаны, они нуждаются в кратком рассказе на человеческом языке зачем они и почему.

Насчет "хороший программист должен уметь писать на любом языке - бред" — аргументируйте. Понятие "писать быстро" я достаточно точно описал. Оно не означает, что вы должны выдумать мегалгоритм за 5 минут. Оно означает, что, выдумав алгоритм (хоть год думайте), его нужно уметь быстро написать на языке программирования. И скорость здесь определяется не умением думать (алгоритм уже придуман), а знанием инструментов. Что согласуется с тем, что нужно знать много, очень много разных технологий, библиотек, фреймворков, техник, практик и т.п. Чтобы не застревать на этапе кодирования.

Жду аргументов.

Аргумент:
напиши "Hello, world!" на 20 языках. И зафиксируй сколько времени на это ушло. Задумайся: нужно-ли оно всё, и зачем?

Hello World никому не нужен, так что пример не в кассу. Когда я говорю, что нужно знать кучу технологий, я подразумеваю, что в реальной работе _действительно_ нужно знать кучу технологий. Отсюда три следствия:
1. Не нужно боятся нового и непонятного.
2. Нужно быстро учиться.
3. Если вы работаете там, где можно три года подряд писать на одной, скажем, Джаве, то это не реальная работа. Это питерская моторола, а не разработка hi-tech продукта. Говоря о софтверных предприятиях, я не беру в расчет пансионаты.

По-моему вообще глупо и неуместно высказывание о том, что программист должен реализовывать алгоритм на множестве языков. Изучая несколько языков, человек обречен на то, что будет путать понятия и языковые парадигмы. В настоящее время необходимо четко определить, в какой сфере ты хочешь быть задействован и в соответствие с этим и изучать язык. Распроняться я не вижу смысла, надеюсь меня поймут. "...в реальной работе _действительно_ нужно знать кучу технологий" - опять же. Это где такая работа? Т.е. я представляю себе программиста, который до обеда прошивает АТС и возится с программным обеспечением станков, после бежит отдел кадров и поднимает рухнувшую базу данных, а потом бежит в офис и работает на C#. Вечером дома работает удаленно с клиентом, что заказает ему проект на Delphi. Олег, ты про такую "реальную работу" говоришь? Это чистой воды кидалово. В нормальной компании тебе и не разрешат заниматься ничем, кроме твоей узкой специализации. Специалист во всем - специалист не в чем.

Ну путаться в парадигмах для хорошего программиста конечно допустимо, но не должно быть систематическим. Да и для вспоминания тонкостей языка всегда существует хэлп, так что это то как раз не страшно.
Другое дело, что одновременно заниматься веб-программированием и например системным не очень хорошо, так как принципы и уровни абстракций совершенно разные.

Дэн, я сейчас занимаюсь веб-программированием и мне очень пригодились знания, почерпнутые из великой книжки «Введение в операционные системы». Дело в том, что наша небольшая веб-система очень сильно нагружена, использует распределение кода приложения и кусков базы данных по физическим серверам и, по сути, вся конструкция представляет собой сетевую ОС. Я, конечно, не разбираюсь во всех тонкостях на каждом уровне (мне банально не хватает знаний о MySQL, сокетах линукса и прочих вещах), отдельные люди в этом разбираются лучше. Но я не могу писать приложение под эту ОСь, не зная как она работает, — она все время меняется в соответствии с нагрузками и функциональностью, красивой книжки с фиксированным API по ней нет, т.к. мы сами её пишем для себя.

Влади, ты привел пример того, как чувак занимается _разными_ делами. У меня есть опыт работы на 3-х работах, где я писал на PHP и Флэше, т.е. не очень разношерстные вещи, но тем не менее это жутко выматывает. Выматывает сама многозадачность, а не многоязыковость. Сейчас у меня одна работа, где я работаю с Flash/AS, HTML+JS, Ruby, PHP, настраиваю Nginx, MySQL-, SMTP-, DRb-серверы и т.п., как часть одного приложения. Мне совершенно очевидно, что кому-то другому я могу отдать разве что внешний вид страничек (что и проделано), а все остальное раскидывать по людям — это будут большие издержки на коммуникацию. Да и работы там немного: тут настроить, там настроить, тут написать скриптик, там поднять демон и убедиться, что все работает. Коллективное здесь то, что по важным вопросам я могу обратиться за помощью к коллегам, которые спецы в какой-то области. Но нет такого "модуля", чтобы дать его кому-то сделать отдельно.

Еще раз: последнюю неделю я много писал на ActionScript, попутно конфигурируя Nginx и дописывая на JS+HTML+Ruby площадку под эту флешовую штуку. И все это в рамках одной цельной задачи. Разделять тут нечего.

нда, с ужасом вспоминаю связку php+JS+HTML+ActionScript+VRML на которой проходилось когда-то писать.
Щас проще...асм+ С++

Готов не согласиться с предыдущими ораторами насчет того, что можно путаться в парадигмах. На самом деле парадигм не так много и путаться в них на мой взгляд недопустимо. Можно путаться в языковых идиомах, что впрочем проходит после более менее продолжительного использования того или иного языка.

Правильно товарищ говорит.

Странно все написанное. Может, у меня и не тот уровень - а может, слишком много практичности. Да, домя я по ночам пишу что-то - сви супер-пупер контролы, ядро системы документооборота... Но вот на работе - мне сказано - пиши проект - и я пишу проект. И никому не интересно, что он будет представлять из себя внутри, как он будет работать. Просто придерживаюсь принципа "некрасиво, но безопасно" - и творю. В сжатые сроки - лишь бы успеть. А отладкой заниматься приходится немного - ибо приоритет на безопасность помогает. И еще. Знания, полученные ребятами в институтах - про "правильный", "красивый" стиль - редко, увы, находят применение в реальной жизни.
Возможно, я ошибаюсь, и люди, которые ведут огромные и сложные проекты, видят все по-другому, но при создании, к примеру, баз данных все выглядит именно описанным мной образом.

э.. на моем предыдущем проекте.. вот такой вот принцип привел к тааааакой заднице... вам видимо очень везло до сих пор..

Ну это стандартная практика )) На самом деле достаточно зар попробовать чтоб понять, что усилия на хорошую архитектуру и регулярный рефакторинг окупаются процентов на 200-300%.
Знания про про крачивый стиль редко находят применение,это да... Но хороший, читабельный код, прямо выражающий мысли автора есть вещь исключительно повседневной необходимости.
Уф... хорошо отпостился, нада завтра руководителю проекта это вгрузить =))

мде :) а что делать программисту на ассемблере + еще реверсеру криптологу и разработчику защит ? кто йа ? программист или ни кто кстате не одной группы в контакте с упоменанием о реверсинге криптографию не смарел лень итаг мозг плавится :

мде нету ничего :( короче видимо я не подхожу под вашу и вобще контаковские группы :) лана пойду создам сам себе группу :) гг

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


вся проблема в том что многие не любят програмирование точнее не вникают полностью в него знают свой язык типа ограниченых высокоуровневых С++ и т.д. ... ( почему ограниченово ? ( высерьезно ? ) мне привести список различий с ассемблером ? )

я лично интересуюсь всем и я просто ассемблерщик кто знает тот поймет ... мне не важны последствия или результат МНЕ ВАЖНО КАК ЭТО РАБОТАЕТ

Дим, я бы рекомендовал тебе для начала русский выучить.
Ну и знаешь ли. У каждого инструмента есть своя ниша. И уровень абстракции, на котором этот инструмент успешно применяется. Да, мне важно знать, как внутри устроены рельсы (это мой инструмент), да.. где-то уметь написать сишный экстешн и ruby-биндинги к нему, но спускаться ниже сейчас мне нет никакого смысла.
Поэтому не вижу никакого смысла в понтах: я крут, я дизассемблерщик, я криптограф, а все вокруг полные лохи.

Кстати на счет твоего неограниченного ассемблера: он жутко ограничен. И то, что ты это не понимаешь, тебя характеризует не с лучшей стороны. Предлагаю подумать минут 15 на тему "Почему веб-приложения НЕ пишут на ассемблере?".

причем здесь веб приложения ? ха ассм ограничен ха ха :) лана я так и думал что сейчас посыпятся очень "умные" коменты :) прикольно :)


кст я не понтовался одно дело если бы я не знал и не умел того что писал тогда это был бы понт а я реально знаю и умею то что писал и уверен в своих знаниях ...

вот пример с орфографией у меня проблема из за моей лени мне лень думать на этом и вот если бы сказал что я пишу по русски без ошибок это был бы понт ... потому что реально мне нада напрягать свой моСК чтобы писать правильно :)

и я не кого не опсирал я грамотно объяснил что вы тупо не видите дальше "закрытой двери" ....

хаха ассм ограничен ЛОЛ я поцтол сполз ты сам то понял что сказал вобще ? гг ................ ну пипец ... слов нету ... лана иди сиди на своем С++ или иже с ним .... слов нету ... просто расмешил реально расмешил :) удачи "ПРОГРАММИСТ " лол ... а нимагу

ДА! Асм ограничен. Ограничен прежде всего твоим МОЗГОМ, твоим ВРЕМЕНЕМ, он хреново МАСШТАБИРУЕТСЯ, у него проблемы с ДЕКОМПОЗИЦИЕЙ как минимум. Мы говорим не о сферическом коне в вакууме, а о реальных вещах. Теоретически на нем пишется абсолютно все (за бесконечное время, бесконечно умным чуваком), практически очень низкоуровневые, требовательные к ресурсам кусочки приложений.

Хмм.. Глупо здесь обсуждать чужие орфографические ошибки: те, кто их допускает, едва ли поймет, что он неправ. Красивая архитектура - это одно, а читаемый и понятный код - это другое. Что действительно стоит делать - так это тратить время на комментарии. Оно себя окупает, когда начинаешь отладкой заниматься. Да и узнаешь кучу иностранных слов - таких, как "фигня", "хрень", "непоймикакработает" и "лучшенетрогать". Просто стоит проанализировать - стоит ли лишний раз создавать красивый и понятный класс, или просто тихонько дернуть три раза из БД то, что там хорошо и проиндексированно лежит.
Очень сложно канонировать - этот код и стиль "хороши", а эти - "плохи". А работал с кодом разных людей - тенденция одна: кто в реальной жизни умеет грамотно и аккуратно излагать свои мысли, у того и код понятен и читаем. Так что читайте классику, господа! :)

ну мы просто разные программисты ... поэтому выше я и писал что сохдам группу буду сидеть один гг :) вот с 59 коментом согласен вплане что на нем долго нада писать простые функции но это мне не мешает ... я сравнивал например работу с базой через ассм ( когда все написанно на ассме включая интерфейс ) с работой тоже С++ ... я воздержусь от коментов .... не спорю на С нада мало времени чтобы написать все это однако после дисассемблирования видны все проблемы высокоуровневых языков ...


ДА Я ПИШУ С ОШИБКАМИ :) достали :) лол давай те переименуем группу в людей пишущих без ошибок :)

Максим, читабельность кода и красота архитектуры свзяны неразрывно, правда. Я долго с недоверием относился к таким идеям, но вот проникся =))

Дима, не надо путать божий дар с яичницой:когда пишут на языке высокого уровня глубоко паралельно, что на асме это выглядит хреново, и работет в полтора раза дольше, требуется быстро писать и быстро дебажить сложные программы. И вообще, спокойней надо, есть программисты-математики и есть программисты-инженеры. Первые любят подгонять кирпичику друг к другу, другие рисовать небоскрёбы =)) То, что человек с другого полюса не значит, что он идиот.

"идиот с другого полюса" =)

я предпочитаю сложные функции писать всетаки на ассме мне проще так ... остальной мусор можно и на С++ например накатать а вот собственно основные функции ... хотя бы самые важные на ассме полюбому ...

Асм кончено хорошо. Сам пишу 80% времени на асме, правда для контроллеров. Так вот для RISC архитектуры ассемблер - это и удобно и быстро и эффективно.
Был несколько опытов переписывания программы, написанной на С++ под VS, на асм x86. Результат меня удивил. Программа написанная на С++ работала быстрее чем то же самое написанное на асме. Решил понять почему, посмотрел дизассемблером. Оказалось, что компилятор+оптимизатор так перепахал сишный код, что узнать его стало не возможно. Плюс ко всему последовательность команд. x86 НЕ RISC, поэтому в нем ОЧЕНЬ важно в какой последовательности выполняются команды асма... так вот, мне если честно лень разбираться как эффективней выстроить команды в ассемблере, пусть этим занимается оптимизатор-компилятор, а я буду тратит время только на написание оптимального алгоритма с точки зрения С++.
Ну а защиты эффективно писать можно и на С, главное понимать, что получишь после дизассемблера.

Ну будем забывать, что Си - все-таки, набор макросов для ассемблера. В том смысле, что почти всегда точно знаешь, какой машинный код получится на выходе компилятора.

Народ что бы нессорится - почитайте книгу "Идеальный код". Лично мне она помогла понять, каким должен быть код. Думаю, поможет и вам. Те кто читал, думаю согласятся.
Правда я программлю на высокоуровневых языках (увы, но ассемблер слишком долог для моих задач). Если бывает нужна производительность - заказываем на стороне. Поэтому считаю, что программеры всякие нужны :) И пишушие на асме, и на php :) Хотя PHP я все же не перевариваю (признаю, что очень удобный для WEB, но все равно не перевариваю :)

Этот топик называется "Хороший программист", а не "Идеальный код" неспроста.

"хороший программист должен уметь писать на любом языке - бред."
Не согласен. Лучше достаточно хорошо разобраться в 2-3х языках, чем посредственно знать 4(честно говоря, и не встречал таких людей, которые бы хорошо(!) разбирались в таком кол-ве языков) и больше. Я сам знаю 2 и изучаю 3-й, но это скорее веяния моды у работодателей. Была бы возможность, все делал бы только на одномi.

Идеальный код - форева. Факт.

мля, пасибки. буду исправлять себя в паре пунктов

Каждая последняя ошибка в вашем коде - предпоследняя

"Каждая последняя ошибка в вашем коде - предпоследняя" - баян. Одна из 3-х стандартных формулировок программотехники %)

Нашел много нового, спасибо.

Советую книгу

С. Макконнелл "Совершенный код" ("Code Complete")
Серия: Мастер-класс

1. Хороший программист должен быть самостоятельным.
Хороший программист должен уметь находить помощь везде, включая своих коллег. Вы здесь рассматриваете какую то маленькую проблему, не забываете, есть очень большие приложения...

2. Реализовывать надо грамотно, с возможностью масштабирования, документацией интерфейсов, чтобы другому было удобно работать, или вам в будущем. Это не бег с припятствиями на время. Затягивать конечно тоже нельзя.

5. Не понял великую мысль... Извините...