Правильный код правила хорошего тона начинающего программиста

Оглавление (нажмите, чтобы открыть):

Правила хорошего тона в программировании

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

1. Всегда делайте отступы

Самое сложное, в неправильно структурированной программе — это найти вообще что бы то ни было. Где начался цикл, где он закончился. Где начало этого блока. Эта переменная участвует в условии, или нет.
Попробуйте сами понять, как это выглядит, например в коде php:

Пример взят из всем известного движка PHP-Nuke.

Так же, при создании отступов, считается наиболее правильным ставить пробелы, а не символы табуляции.
Честно говоря, я считаю, что это на любителя. Я, лично, люблю табуляцию. Так как это быстрее и легче. Но если для вас нет никакой разницы, то лучше использовать пробелы. За это многие скажут спасибо.

2. Используйте понятные названия

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

$je34a — неверно.
$user_age — верно.

Вполне очевидно, для чего это все надо. Даже если вы считаете, что ваш проект небольшой и над ним никто не будет работать. И если вы считаете, что у вас отличная память, все равно используйте понятные названия. Проект может стать большим. Вы сами можете рефакторить ваш проект спустя какое-то продолжительное время и т.д. И в этом случае ваша память, либо ваши последователи скажут вам спасибо, а не другие, известные всем слова.

3. Не начинайте программировать сразу

Я понимаю, всегда возникает желание, при возникновении идеи, сразу с головой бросаться в бой с кодом, но, если ваш проект имеет хоть какую нибудь мизерную возможность стать больше и шире, то спроектируйте архитектуру приложения на бумажке, либо с помощью любого другого, более удобного вам инструмента.
Чем более продумана архитектура приложения, тем легче ее в будущем расширять и дописывать. Тем меньше сил уйдет на то, чтобы сделать всю работу сначала, но «по правильному».

4. Комментируйте

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

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

прикладная математика

Правила хорошего кода — 27 советов

Написание красивого и эффективного программного кода — целое искусство, во многом, увы, подзабытое в связи со взрывным ростом мощности вычислительных устройств, вызвавшим снижение требований к качеству алгоритмов. Это небольшое приложение не может заменить изучения специализированных дисциплин вроде «Технологии программирования» или «Теории алгоритмов и формальных языков», но следование изложенным здесь принципам позволит начинающему программисту привыкать не просто «решать задачи», а делать это возможно более красивым и экономичным с точки зрения вычислительных затрат способом.

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

2. Давайте переменным осмысленные имена. Переменная с именем Length, или, в крайнем случае, Dlina, сама напомнит о своем назначении, в отличие от L. С другой стороны, не возбраняется использовать стандартные сокращения — например, S для площади, P для периметра, a, b и c — для сторон треугольника. Любые индексы естественно выглядят с именами i, j, k и т. д. Но если индекс обозначает номер месяца в году, куда естественней назвать его month, чем i. Хотя Паскаль и не различает регистр букв в именах переменных и служебных словах — соблюдайте его везде. Большинство профессиональных языков регистр символов различают.

3. Существует множество соглашений об именах переменных — можно спорить об их достоинствах и недостатках, но бесспорно одно — соблюдение единообразного стиля именования намного облегчает понимание и модификацию программы. В сложных проектах осмысленных имен переменных может оказаться недостаточно, тогда на помощь придут префиксы. Так, если все имена всех переменных, относящихся к таблице «Студенты», начинаются на st_, а все динамические указатели имеют в имени префикс ptr_ (от англ. «pointer» — указатель), читать такую программу будет намного проще.

4. Создавая любую переменную, обратите внимание на следующие моменты:

· какой тип значений может принимать переменная, нельзя ли заменить ее перечислением, множеством или иным «сокращенным» типом данных?

· есть ли ограничения на допустимые значения, если да, где и как они будут учтены? · что произойдет при переполнении значения или попытке дать переменной недопустимое значение?

5. Закрывайте блоки сразу. Такой блок, как

if условие then begin end else begin end;

while условие do begin end;

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

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

7. Доводите программу до отсутствия предупреждений компилятора, а не только ошибок. Неизвестно, как скажутся на самом деле эти «невинные» напоминания. В языке Си конструкция вида if a:=0 допустима и вызовет лишь предупреждение «Possibly incorrect assignment» — хотя в результате переменная a всегда будет получать значение 0 и ветвь алгоритма, привязанная к этому условию, будет всегда выполняться.

8. Выбирайте более короткие типы данных там, где это уместно: часто byte может заменить word или integer, а string[20] — просто string.

9. Применяйте возможно более эффективный алгоритм решения — прежде всего, оценка эффективности связана с зависимостью числа выполняемых операций от размерности данных. Двойной цикл полной обработки всех элементов матрицы прост в изучении, но далеко не всегда является лучшим решением при работе с реальной задачей — ведь трудоемкость этого алгоритма равна n2, где n — размерность матрицы.

10. Выбирайте менее трудоемкие операции. Так, n div k лучше, чем Trunc(n/k), а Inc(i); лучше, чем i:=i+1;. Во всех случаях порядковые операторы и операнды работают быстрее, чем вещественные. Поэтому обходитесь порядковыми данными везде, где это возможно. Особенно избегайте без необходимости деления на вещественные числа.

11. Не забывайте о погрешностях при работе с вещественными числами. Хрестоматийное while x 0) and (y>0) or (x 0) then .

18. Прекращайте циклы, когда результат уже достигнут. Приоритет средств при этом следующий:

· использование циклов repeat-until или while-do вместо for; · операторы break или exit; · в последнюю очередь — goto, и только в случаях, описанных в п. 16.2.

19. Временный «рабочий» массив того же порядка, что создаваемый или прочитанный из файла — почти всегда не лучшее решение. Его использование говорит о том, что задача решается «в лоб» и не оптимальным способом. Допустимым считается использование одномерного рабочего массива при обработке матричных данных — если размерность его не превышает большей из размерностей матрицы.

20. Именуйте размерные константы массивов. Никому не нужны несколько циклов с верхними границами-«близнецами». А что, если размерность обрабатываемых данных придется изменить?

21. Передавайте значения подпрограммам преимущественно по адресу, а не по значению. Для матричных и векторных данных старайтесь делать это всегда. Применение векторных данных имеет приоритет перед матричными.

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

23. Не пишите подпрограмм, возвращающих более одного объекта — скаляра, вектора или матрицы. В крайнем случае, можно отдельным параметром передавать или возвращать размерность векторных данных. Избегайте подпрограмм, которые ничего не возвращают. Разработка сложных подпрограмм облегчается, если их «точка выхода» и возвращаемое значение указаны единственным и последним оператором. Для перехода из тела подпрограммы в точку возврата в этом случае не грешно использовать даже goto:

Этикет программирования – то, что заставит других разработчиков меньше вас ненавидеть

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

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

Я спас вас от многолетнего повторения ошибок, собрав их в одном месте.

0. Комментируйте код

Что может быть хуже кода без комментариев? Если вы скажете – что угодно, вы ошибетесь. Если вы собираетесь как-то улучшить код – убедитесь, что он сопровождается комментариями. Комментируйте «громко и гордо».

Только что дописали большую и важную функцию? Сделайте одолжение себе и миру – опишите, что она делает и как ее использовать. Вы поблагодарите себя за это спустя полгода. К тому же, это позволит вам избежать смертельной угрозы, написанной в двоичном коде одним из участников команды.

1. Теперь сделайте комментарии осмысленными

Вы пишете комментарии! Отлично. Теперь важно, чтобы ваши комментарии в короткой и ясной форме описывали суть происходящего. Помните, каждый из нас по-разному представляет единорога, мы все думаем по-разному. У Джедиса нет времени на расшифровку клингонского языка из сериала Star Trek (или ваших межгалактических метафор).

Вы также должны избегать слишком очевидных комментариев, как в примере ниже:

Если вы пишете код, который является очевидным даже для новичка, не беспокойтесь о комментировании. Мы искренне ценим энтузиазм и приверженность делу, но некоторые вещи действительно не требуют пояснений.

2. Не превращайте ваш код непонятно во что

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

Есть какие-то идеи по поводу того, что делает этот блок? Полагаю, Мегатрон голоден?
Тот же принцип следует отнести и к коротким именам переменных. Если вы не используете общепринятые стандартные аббревиатуры, используйте полные слова. Случайный набор букв запутает почти любого программиста, читающего ваш код.

Мы понимаем это. Это ведь самое главное, правда?

Если ваши переменные названы как в примере ниже, значит вы на верном пути.

3. Деревья не только для птиц

Теперь, когда вы пишете комментарии и классно именуете переменные, вы прошли половину пути. Мои поздравления! Теперь настало время сделать код удобочитаемым. Вложите друг в друга ваши блоки кода, чтобы показать наличие древовидной иерархии. Правильно структурированный HTML-код подобно ветру принесет правильный CSS-код.

Попробуйте еще раз:

Конечно, вы возразите, что инспектор кода в любом случае добавит отступ в ваш код, но если ваш код не выглядит как в инспекторе, как, черт возьми, кто-то поймет, что где-то не хватает двойных кавычек?

4. Следуйте стандартам сообщества

Основные принципы, перечисленные выше, помогут вам попасть на вечеринку, но если вы хотите на ней задержаться, нужно учесть еще кое-что. Любое сообщество, например WordPress, Django, или jQuery имеет свой набор стандартов кодирования. Следуйте этим стандартам.

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

  • Для большей информации о стандартах в WordPress, сверяйтесь WordPress Codex.
  • Для сверки со стандартами Python, смотрите PEP 8 Style Guide.
  • Стандарты для других языков ищите в Google.

5. И наконец… Повеселитесь

Программирование является одной из тех великих профессий, где мы можем носить джинсы, футболки и бороды на работу каждый день. Это предполагает море веселья. С кодом вы можете сделать невероятные вещи, — вещи, которые буквально могут изменить мир.

Но когда вы проводите бессонные ночи в попытках исправить одну ошибку в IE7, оставленную вами (или кем-то, пожелавшим остаться неизвестным), среди двух тысяч строк CSS-кода – это не приносит радости.

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

Страница поста от канала Библиотека программиста

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме

Пожаловаться

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме

Правила оформления качественного кода. Как правильно оформлять код.

Время чтения: 10 минут

Во время написания кода начинающие программисты зачастую даже не задумываются над тем, как именно следует его оформлять. «Да и зачем? — думают они. — Программа же и так прекрасно работает!». Для очень маленьких учебных задач и проектов, возможно, это допустимо, однако не просто же так крупные компании, как например, Google, создают огромные гиды (code style guide) с правилами написания кода внутри компании. Если вы действительно хотите развиваться как программист, превращаясь из начинающего кодера в крутого профессионального разработчика, то правил написания кода избежать попросту не удастся. Да и зачем избегать, если умение корректно оформить код является ценным навыком, поскольку в разы облегчает работу тех программистов, которым придётся с вами работать! В нашей статье речь будет идти в основном про языки C и C++, однако большую часть из них легко перенести на любой другой язык программирования.

Мастер Йода рекомендует:  Подборка фреймворков и инструментов для iOS-разработчика 2020

Отступы и пробелы в коде

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

Отделяйте пробелами фигурные скобки.

Переносите объявления нескольких переменных на новые строки.

Отделяйте пустой строкой объявления переменных и действия с ними (кроме присваивания):

Разделяйте пробелами операторы и операнды:

Если строка стала слишком длинной, разделите её на несколько, сделав перевод на новую строку после оператора:

Разделяйте пустой строкой реализации функций:

Пропускайте пробел перед открывающей фигурной скобкой, а также перед открывающей круглой скобкой после операторов if , for , while , switch и тд:

Скобки и пустые строки

Не добавляйте пустую строку после открывающей ( < ) и перед закрывающей ( >) фигурными скобками:

Добавляйте после закрывающей фигурной скобки ( > ) пустую строку, но только если за ней что-то есть и это не ещё одна закрывающая скобка:

Разделяйте логически связанные группы выражений, добавляя пустую строку между ними:

Переменные, функции, константы и их названия

«Как вы яхту назовёте, так она и поплывёт!» — пелось в песенке капитана Врунгеля. Вот и в программировании примерно так: как вы переменную назовёте, так она и должна использоваться! Опытные программисты даже могут не один час провести в раздумьях всего лишь из-за поиска подходящего названия!

Давайте переменным имена, по которым сразу будет понятно, для чего они используются: если нужно посчитать сумму положительных элементов массива, логичнее будет назвать переменную sumOfPositiveElement , нежели просто s или sum . Или если требуется найти среднее из элементов, назовите переменную average или avg . Старайтесь избегать однобуквенных названий вроде x или c (к этому совету не относятся переменные циклов вроде i , j и тд.).

В зависимости от используемого языка слова в именах переменных разделяются либо с помощью символа нижнего подчёркивания, либо через верблюжийРегистр (каждое новое слово записывается с заглавной буквы). Если же таковые правила отсутствуют, выберите наиболее удобный вам и всегда придерживайтесь его в дальнейшем. Классы обычно называются в ПаскальномРегистре , а константы или макросы в ВЕРХНЕМ_РЕГИСТРЕ .

Если переменная используется внутри определённого if или while блока, то делайте её локальной, объявляя в том же блоке кода, а не глобальной:

Избегайте «магических» констант в коде (простые, ничего не значащие цифры). Обозначьте их как const и ссылайтесь на константы, а не на значения:

Циклы и условные операторы

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

Используйте цикл for , когда количество повторений заранее известно, а цикл while , если число итераций заранее посчитать невозможно:

При использовании операторов цикла ( for / while / do-while ) или условных операторов( if / else ) всегда ставьте фигурные скобки и соответствующие отступы, даже если тело всего оператора состоит всего из одной строки:

Старайтесь свести практику использования операторов break и continue к минимуму, а лучше вовсе откажитесь от неё. Используйте их только в случае крайней необходимости.

Используя оператор if / else , избегайте проверки лишних условий внутри операторов:

Если вам требуется вернуть логическое выражение, записанное внутри if / else , возвращайте это выражение:

Повторение частей кода

Если вы используете один и тот же код более одного раза, найдите способ удалить лишнее или перенесите его в отдельную функцию и вызывайте её вместо старых блоков. Если повторяющийся код похож лишь частично, то постарайтесь вынести различающиеся части в параметры вспомогательной функции:

Если какой-то код повторяется во всех частях if / else блока, то вынесите этот код за пределы условного оператора:

Эффективность

Вызывая большую функцию и используя результат несколько раз, сохраните результат в переменной вместо того, чтобы постоянно вызывать данную функцию:

Программист, сооснователь programforyou.ru, в постоянном поиске новых задач и алгоритмов

Языки программирования: C, C++, Pascal, C#

Студент МГУ им. М.В. Ломоносова

А Вы знаете, что мы пишем программы на C, C++, C#, Pascal и Python?

Так что если Вам нужно написать программу на C/C++, C#, Pascal или Python — мы с радостью поможем с этим!

В том числе мы занимаемся репетиторством по информатике и программированию, а также готовим к ОГЭ и ЕГЭ!

Почему именно мы?

  • Более 1800 выполненных заказов;
  • Более 170 отзывов;
  • Качественное решение
  • Короткие сроки и привлекательные цены
  • Различные акции и скидки

Как с нами связаться?

  • группа Вконтакте: vk.com/programforyou
  • наша почта: order@programforyou.ru

Programforyou — позвольте нам писать код для вас и вы получите качественное решение в короткие сроки по привлекательной цене!

Пятничное. О стилях и правилах хорошего тона в программировании в том числе 1С.

Уважаемые участники форума!
Прошу высказать свои мысли о стилях и правилах программирования, копипасты и ссылки приветствуются.

Прошу не спорить, прошу просто высказывать мысли.

Как известно 20% усилий приносят 80% результата.
Итак:
1. Старайтесь поставленную задачу разбить на модули и отдельные блоки, и нарисуйте блок-схему (по чертежу Вам будет гораздо проще ее реализовать).
2. Не изобретайте велосипед или колесо. Старайтесь по возможности использовать готовые разработки и библиотеки, т.к. это значительно ускорит процесс программирования и избавит от лишних ошибок.
3. Постарайтесь продумать хотя бы пару вариантов реализации, из которых в последствии можно выбрать наиболее удачные.

А так же можно что-нибудь про правила хорошего тона (наш код потом будут читать другие) в 1С.

Для начинающих программистов) Или как начать кодить на С++. Длиннопост

Дубликаты не найдены

Изучающим С++ рекомендую следующую последовательность обучения:

1. Харви Дейтел и Пол Дейтел «Как программировать на С++», чтобы понять азы языка
2. Герб Саттер и Андрей Александреску «Стандарты программирования на С++», чтобы знать многие «тонкие» моменты языка
3. Скотт Мейерс «Эффективное использование C++» и «Эффективное использование STL», чтобы уметь пользоваться стандартным
инструментарием
4. Герб Саттер «Новые сложные задачи на C++», чтобы уметь избегать коварных ошибок
5. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес «ООП. Паттерны проектирования», чтобы знать стандартные методы и приемы
6. Андрей Александреску «Современное проектирование на C++», чтобы знать, как правильно проектировать программы
7. ISO/IEC 14882 «Programming Language — C++», основополагающий документ — стандарт языка С++.

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

Пункты 6 и 7 не для новичков. Чтение п. 6 рекомендую не менее, чем через год плотной практики.
Пункт 7 приведен скорее для порядка, чем для реального чтения, так как читать его сущее мучение.
С другой стороны, если возникла серьезная ошибка компиляции, и есть подозрения, что виноват компилятор,
то в первую очередь нужно проверить в стандарте, так ли это.

Если нет надежного доступа в интернет, то можно так же приобрести справочники:
1. Герберт Шилдт «Полный справочник по С++»
2. Дэвид Вандевурд и Николай М. Джосаттис «Шаблоны С++. Справочник разработчика»

Правильный код: правила хорошего тона начинающего программиста. #[email protected]

Прежде чем начать писать правильный код, должно пройти немало времени. Вот правила, которые помогут изменить к лучшему качество кода.

Правильный код: правила хорошего тона начинающего программиста

Комментарии (21)

DELETED

ну сделайте блин сразу ссылку на источник..что ли..

Денис Кузнецов

Евгений, Сами ж придумали =)

Александр Савинов

Пост со ссылкой на страницу, которая содержит лишь.. ссылку на ещё одну страницу !? Да ещё, в результате, всё ведёт на 4 совета, че-ты-ре, Карл. Которые, притом, исключительно для джавистов.

Денис Кузнецов

Меня больше всего бесит то, что тут советы в бОльшей степени к джава-разрабам, когда как статья для программиста. То есть, для всех типов, сечете фишку?

Денис Кузнецов

Александр, Надо больше переходов богам переходов!

Матвей Бельский

Правило №4: применяйте “unlift” везде, где возможно

Евгений Гриценко

1. «Бросайте исключение по любому случаю» — ага, в С/С++ бросайте, особенно когда у вас критичный проект, например браузер и механизм исключений только будет затормаживать. 2. «Используйте строгую типизацию» — очень «подходит» для языков с нестрогой типизацией, отличный совет. Учитывая что типизация — свойство языка. Итого, кратко пробежавшись, половина статьи это не советы начинающему программисту на любом языке, а сборник сомнительных рекомендаций для Java junior. Вместо этого неплохо было бы посоветовать выбрать и следовать CodeStyleGuide’у нужного языка. Держать код простым и явным, без излишней сложности и перегруженности.

Данил Сидоров

Евгений, может проще было сделать ссылку на Мартина а не публиковать такое?

Евгений Гриценко

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

Данил Сидоров

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

Евгений Гриценко

Данил, может и не все, а многое

Данил Сидоров

Евгений, ну вот может стоило бы взять пару вытяжек из Мартина и дать ссылку ?* опять же если не изменяет память первая книга у него по Джаве а вторая уже рассматривает примеры на нескольких языках.

Евгений Гриценко

Данил, разумно, надеюсь админ обратит внимание, хотя.

Правила плохого и хорошего тона в программировании — мнения экспертов

Пока спрос на программистов в ИТ-индустрии и за ее пределами достаточно высокий. Но в любой отрасли «хороший» специалист ценится всегда, вне зависимости от ее популярности. Возникает вопрос, как стать таким специалистом? Какие критерии профессионализма высокого уровня можно выделить? Ответы на эти вопросы во многом зависят от конкретных работодателей.

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

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

Среди профессионалов всегда существуют какие-то договоренности. Это выражается, например, в том, что в свое время сформировались различные парадигмы и стили программирования. Однако, прежде всего, существуют некие базовые требования, которые предъявляются к профессиональным программистам независимо от направления и стиля разработки.

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

Признаки плохого программиста

Распространенным и одним из главных признаков считается неспособность «выполнять программу в голове». Если перед вами человек с красивыми должностями в резюме, но он не может написать простой алгоритм на бумаге, лучше с ним не связываться.

На «Хабре» в свое время был пост, в котором обсуждались признаки плохого программиста:

• наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается;

• исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода;

• «йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали

• «бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.

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

Сложности с указателями

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

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

Сложности с рекурсией

Идею рекурсии достаточно легко понять, но у программистов часто возникают проблемы с тем, чтобы представить результат рекурсивной операции или насколько сложные вычисления могут быть произведены с простой функцией. Проблемы с представлением «где вы находитесь», когда вы начинаете писать условие продолжения рекурсии, или с формализацией параметров рекурсивной функции могут сделать разработку рекурсивной функции очень сложной для вас.

Следование договоренностям

Если разработчик пишет код по принципу «работает, и ладно», его вряд ли можно считать профессионалом высокого уровня. Ведь это противоречит принципам всех парадигмам программирования – объектно-ориентированной, функциональной, декларативной и так далее. Такой подход затрудняет или делает практически невозможной коллективную разработку. Подобное отношение характеризует человека как ригидного, поверхностного, не желающего углублять свои знания и совершенствовать навыки.

@victorb, автор упомянутого выше поста указывает следующие «симптомы», связанные с неумением следовать парадигме разработки:

• использование любого необходимого синтаксиса для того, чтобы «вырваться» из предлагаемой языком модели, и написание оставшейся части программы в императивном/процедурном стиле;

• (ООП) Попытки вызова не статических функций или присвоения переменных в неинстанциированных классах, проблемы с пониманием, почему такие конструкции не компилируются;

• (Реляционное) Обращение с базой данных как с хранилищем объектов, исполнение всех JOIN’ов и проверки целостности на клиентской стороне;

• (Функциональное) Создание многих версий одного и того же алгоритма для обработки разных типов или операторов вместо передачи функций высшего порядка обобщенному алгоритму;

• (Декларативное) Установление индивидуальных значений в императивном коде вместо использования связывания данных (data binding).

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

Мы пообщались с экспертами российской ИТ-индустрии и выяснили их мнение по поводу хороших и плохих программистов, а также попросили дать пару советов начинающим.

Максим Нальский, основатель сервиса Pyrus:

Какими качествами должен обладать хороший программист?

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

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

Мастер Йода рекомендует:  Создание страницы архива на основе изображений начало работы

Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?

Умение написать легко читаемый, компилируемый, проходящий автотесты, работающий код — главный критерий.

Дайте, пожалуйста, «вредные советы», правила плохого тона для начинающих программистов.

Если хотите стать плохим программистом — идите на курсы, слушайте лекции, только ни в коем случае не программируйте сами. Некоторые так и делают — штудируют учебники, потом сдают экзамены, получают бумажки, сертификаты.

Когда я читаю резюме с длинным списком сертификатов, я вижу, как человек тратил время своей жизни, не совершенствуясь в навыках создания надежного софта, а получал оценки.

Руслан Фазлыев, СЕО Ecwid:

Какими качествами должен обладать хороший программист?

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

Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?

Отличить хорошего программиста – по тому, что он создал и насколько быстро решает простые задачи. Сложные задачи состоят из простых, и, если программист легко владеет атомарными кубиками, он будет результативен.

Может ли хороший программист быть перфекционистом? Почему?

Хороший программист может быть кем угодно – лентяем, перфекционистом, занудой. Использовать эти сильные стороны и митигировать слабые – задача хорошего инженерного менеджера.

Должны ли компании опасаться программистов-перфекционистов? Почему?

Их не нужно опасаться, ими нужно управлять. Частые промежуточные дедлайны – обязательно для перфекционистов, если у них не «рожается» код, нужно делать «кесарево».

Как вы относитесь к тому, что большую часть кода для решения задач разработчик берет из интернета?

Отлично, если это ускоряет результат.

Должен ли хороший программист использовать выражения return true или return false в циклах? Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов? Правда ли, что хороший программист почти не использует оператор «else» и ему подобные?

Хорошему программисту нужно заниматься тем, чтобы сегодня же код работал у клиента. Игрок должен забивать голы, как он это делает – не важно. Опасайтесь слова «архитектура» от программистов. Говоря же о красоте кода – прекрасно, когда она есть естественно и по ходу дела, и да, море «if’ов» – не красиво и глюкоопасно. Но я не хочу это обсуждать с программистом: все, что я хочу знать – когда будет готов протестированный качественный релиз.

Дайте, пожалуйста, «вредные советы», правила плохого тона для начинающих программистов.

Все счастливые семьи счастливы одинаково, быть несчастным есть миллион способов. Первейший способ быть плохим программистом – лениться, гордиться, и искать сложных решений там, где есть простые.

Евгений Потапов, гендиректор «Сумма АйТи»:

Какими качествами должен обладать хороший программист?

В отличнейшей книге Coders at work (серии интервью с известными разработчиками) — один из главных вопросов «каким образом вы изучаете чужой код?».

Хороший программист это тот, кто может поддерживать чужой проект, тот кто может после запуска продолжать дописывать свой код, тот, чей код могут поддерживать другие люди.

Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?

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

Может ли хороший программист быть перфекционистом? Почему?

Может, если это не будет идти во вред производительности. К сожалению, почти наверняка идет, а в современном бизнесе время до деплоя куда важнее идеальности кода в большинстве случаев (пока вы не пишете медицинский софт и не запускаете людей в космос).

Должны ли компании опасаться программистов-перфекционистов? Почему?

Должны, но компании должны спрашивать отзывы с предыдущих мест работы, и если там все хорошо — сильно не бояться.

Как вы относитесь к тому, что большую часть кода для решения задач разработчик берет из интернета?

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

Позволительно ли хорошему программисту хронически не помнить некоторые алгоритмы и синтаксические конструкции языков, которыми он пользуется в работе? Почему?

Очень сильно зависит от уровня незнания. Базовые вещи надо, конечно, знать

Должен ли хороший программист использовать выражения return true или return false в циклах? Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов? Правда ли, что хороший программист почти не использует оператор «else» и ему подобные?

Хороший программист это не тот, кто не пишет goto, делает return там, где это положено, и знает все паттерны ООП из Gang of Four на зубок.

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

Виктор Шабуров, технический директор Snapchat:

Какими качествами должен обладать хороший программист?

Smart and get things done.

Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?

Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.

Может ли хороший программист быть перфекционистом?

Да, это очень хорошо.

Должны ли компании опасаться программистов-перфекционистов? Почему?

Я не опасаюсь, наоборот люблю. Менеджер должен конечно ставить цели и контролировать их исполнение в срок. Но в целом это классное качество, если оно сочетается со скоростью программирования и целеустремленностью.

Должен ли хороший программист использовать выражения return true или return false в циклах?

Лет 10 назад, когда я еще кодировал, ответ был «нет».

Правда ли, что хороший программист обычно старается использовать меньше условных операторов?

Надо писать красивый код и использовать столько if, сколько нужно. В Java, например, пользоваться && и ||, чтобы сократить if.

Правда ли, что хороший программист почти не использует оператор «else» и ему подобные?

Я использовал else, когда было нужно, но есть тонкости.

Дайте, пожалуйста, «вредные советы», правила плохого тона для начинающих программистов.

Лучше я дам хорошие советы — постоянно работать над собой, улучшать свои навыки программирования и по мере роста переходить в более крутые компании. Чем сильнее программисты на проекте — тем интереснее работать и большему научишься.

Так же смотреть не столько на зарплату, сколько на перспективу проекта и выделяемые акции компании. В успешном проекте с сильной командой, как Looksery или Machine Learning Works, на акциях можно в десятки раз больше заработать, чем получить зарплатой за это период.

Становление «хорошего» программиста сводится не только к исправлению чисто технических недостатков. Как и любой специалист, он должен уметь общаться с коллегами, и когда нужно, с клиентами. Умение адекватно воспринимать обратную связь, критику считаются не менее важными качествами, чем способность к усвоению алгоритмов и технологий разработки ПО.

Правильный код: правила хорошего тона начинающего программиста

Приходил человек устраиваться на работу, приносил тексты программ. В одном проекте у него 20 форм. Разница у большенства этих форм только в Caption и они все в Auto-Create.
Конечно, главный аргумент — «мне удобнее и быстрее делать так», тем более, если руководитель(заказчик) разницы не видел.
И таких вот программиств дохрена, они даже занимают реальные
должности. Судя по назначении их программ и автобиографии.

Берутся тексты соискателей на работу, делается поиск по StrToInt, и если этот самый StrToInt неоправдано используется — сразу в урну.
А прочитал бы этот юзер раньше: «Не храните данные в конторолах», даже без объяснений — почему. И программы бы у него всегда отличались структурностью и самодокументированностью. Он бы и сам себя как кодера уважал больше.
Вот сейчас разбираю код. Писал уважаемый человек — преподаватель информатики, полковник. Заводит глобальную переменную, а потом юзает её, где как локальную, а где как буфер между функциями. Я не говорю уже о других «примудростях». Черт ногу сломает в таком коде.
«ТАК ВЕДЬ РАБОТАЕТ»
Ненавижу!
Если бы кто-то, когда-то взялся собрать «свод законов» о правилах хорошего тона в программировании, об азах, сей документ был бы куда полезнее всяких факов. Потому что без этих правил кодить можно, а без факов — нет.

Приходил человек устраиваться на работу, приносил тексты программ. В одном проекте у него 20 форм. Разница у большенства этих форм только в Caption и они все в Auto-Create.
Конечно, главный аргумент — «мне удобнее и быстрее делать так», тем более, если руководитель(заказчик) разницы не видел.
И таких вот программиств дохрена, они даже занимают реальные
должности. Судя по назначении их программ и автобиографии.

Берутся тексты соискателей на работу, делается поиск по StrToInt, и если этот самый StrToInt неоправдано используется — сразу в урну.
А прочитал бы этот юзер раньше: «Не храните данные в конторолах», даже без объяснений — почему. И программы бы у него всегда отличались структурностью и самодокументированностью. Он бы и сам себя как кодера уважал больше.
Вот сейчас разбираю код. Писал уважаемый человек — преподаватель информатики, полковник. Заводит глобальную переменную, а потом юзает её, где как локальную, а где как буфер между функциями. Я не говорю уже о других «примудростях». Черт ногу сломает в таком коде.
«ТАК ВЕДЬ РАБОТАЕТ»
Ненавижу!
Если бы кто-то, когда-то взялся собрать «свод законов» о правилах хорошего тона в программировании, об азах, сей документ был бы куда полезнее всяких факов. Потому что без этих правил кодить можно, а без факов — нет.

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

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

Согласен с автором. Мне тоже приходилось разбираться с исходниками одного профессионального программера, ему уже за 40.
На каждом шагу изобретен новый велосипед.
Смотрю новая функция fround4. Ищу ее код, нахожу в файле Utils. Код состоит из одной строки — вызов функции round.
И это самый простой велосипед.
Я бы заставлял всех, кто собирается заниматься программированием проходить медицинскую экспертизу, как водители для получения прав на вождение. Особенно психиатора.

Согласен с автором. Мне тоже приходилось разбираться с исходниками одного профессионального программера, ему уже за 40.
На каждом шагу изобретен новый велосипед.
Смотрю новая функция fround4. Ищу ее код, нахожу в файле Utils. Код состоит из одной строки — вызов функции round.
И это самый простой велосипед.
Я бы заставлял всех, кто собирается заниматься программированием проходить медицинскую экспертизу, как водители для получения прав на вождение. Особенно психиатора.

Значит я один такой придирчивый.
А вот не приходилось вам править чужой код. Никакое документирование не спасет, если там гемерой один.

Значит я один такой придирчивый.
А вот не приходилось вам править чужой код. Никакое документирование не спасет, если там гемерой один.


> int64 (07.04.04 10:59) [4]

Только этим и занимаюсь практически :-)). Правда того о чем ты писал нет. Таких не дёржють :-))).
Я просто имею в виду, что чего психовать-то? Спокойнее надо быть.


> int64 (07.04.04 10:59) [4]

Только этим и занимаюсь практически :-)). Правда того о чем ты писал нет. Таких не дёржють :-))).
Я просто имею в виду, что чего психовать-то? Спокойнее надо быть.

Тейксейра, Пачеко, Delphi 5, руководство разработчика, глава 6.

Тейксейра, Пачеко, Delphi 5, руководство разработчика, глава 6.

Игорь Шевченко © (07.04.04 11:03) [6]
Игорь, тама хорошие советы бесспорно, но мало. 🙂 На все случаи не помогет.

Игорь Шевченко © (07.04.04 11:03) [6]
Игорь, тама хорошие советы бесспорно, но мало. 🙂 На все случаи не помогет.

Игорь Шевченко © (07.04.04 11:03) [6]
Там больше о форматировании и именовании идентификаторов.
Я знаю контору, где за несоответсвие таким стандартам штраф 5$.

Игорь Шевченко © (07.04.04 11:03) [6]
Там больше о форматировании и именовании идентификаторов.
Я знаю контору, где за несоответсвие таким стандартам штраф 5$.

2 int64 (07.04.04 10:59) [4]
нет ты не один такой придирчевый.
Но просто у каждого свой стиль прграмирования. и с эти ничего нельзя сделать.

2 int64 (07.04.04 10:59) [4]
нет ты не один такой придирчевый.
Но просто у каждого свой стиль прграмирования. и с эти ничего нельзя сделать.

2int64 (07.04.04 10:59) [4]
Чужой код править — занятие неблагодарное. Лучше свой написать. (ИМХО, конечно).

2int64 (07.04.04 10:59) [4]
Чужой код править — занятие неблагодарное. Лучше свой написать. (ИМХО, конечно).

Vovchik_A © (07.04.04 11:15) [10]
Переписать все нафиг..ю (с) Российский программист

Кстати, а где можно эту байку прочесть?

Vovchik_A © (07.04.04 11:15) [10]
Переписать все нафиг..ю (с) Российский программист

Кстати, а где можно эту байку прочесть?

pasha_golub © (07.04.04 11:06)


> хорошие советы бесспорно, но мало. 🙂 На все случаи не
> помогет

Опыт, сын ошибок трудных. Оно рулез 🙂

int64 (07.04.04 11:12)

> Я знаю контору, где за несоответсвие таким стандартам штраф
> 5$.

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

pasha_golub © (07.04.04 11:06)


> хорошие советы бесспорно, но мало. 🙂 На все случаи не
> помогет

Опыт, сын ошибок трудных. Оно рулез 🙂

int64 (07.04.04 11:12)

> Я знаю контору, где за несоответсвие таким стандартам штраф
> 5$.

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

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

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

2serge35 (07.04.04 11:19) [13]
Совершенно согласен. Глубокое и грамотное ТЗ это 50% если не 70% успеха. Жаль только, что это случается редко.

2pasha_golub © (07.04.04 11:16) [11]

2serge35 (07.04.04 11:19) [13]
Совершенно согласен. Глубокое и грамотное ТЗ это 50% если не 70% успеха. Жаль только, что это случается редко.

Мастер Йода рекомендует:  Расширенная аналитика для страниц от Facebook

2pasha_golub © (07.04.04 11:16) [11]

int64 (07.04.04 11:12) [8]
Блин, вот нам бы так

int64 (07.04.04 11:12) [8]
Блин, вот нам бы так


> Я знаю контору, где за несоответсвие таким стандартам штраф
> 5$

И что, текучка программистов там просто большая или очень большая?
Уже неоднократно замечено, что каждый новый начальник пытается насадить свой формат расстановки скобок, отступов, заглавных-строчных букв и прочей белиберды.
Если программист грамотный, он пишет такой код, что поймет его и он сам через год, и любой другой программист. А всякое палево «перед begin ставить два пробела, а For писать с большой буквы» — пустая трата времени и удовлетворение непонятных амбиций со стороны людей, занимающихся издательством такой бессмыслицы. А зачастую — банальное прикрытие собственной некомпетентности или повод платить программистам меньшую зарплату за счет таких штрафов.
Работать в таких конторах крайне противопоказано. Имхо.


> Я знаю контору, где за несоответсвие таким стандартам штраф
> 5$

И что, текучка программистов там просто большая или очень большая?
Уже неоднократно замечено, что каждый новый начальник пытается насадить свой формат расстановки скобок, отступов, заглавных-строчных букв и прочей белиберды.
Если программист грамотный, он пишет такой код, что поймет его и он сам через год, и любой другой программист. А всякое палево «перед begin ставить два пробела, а For писать с большой буквы» — пустая трата времени и удовлетворение непонятных амбиций со стороны людей, занимающихся издательством такой бессмыслицы. А зачастую — банальное прикрытие собственной некомпетентности или повод платить программистам меньшую зарплату за счет таких штрафов.
Работать в таких конторах крайне противопоказано. Имхо.

> Смотрю новая функция fround4. Ищу ее код, нахожу в файле Utils. Код состоит из одной строки — вызов функции round.
> И это самый простой велосипед.

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

> Смотрю новая функция fround4. Ищу ее код, нахожу в файле Utils. Код состоит из одной строки — вызов функции round.
> И это самый простой велосипед.

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

На www.xprogramming.ru предлагался в частности стандарт для Дельфи.

На www.xprogramming.ru предлагался в частности стандарт для Дельфи.

Nikolay M. ©
Нужно просто фильтр написать который у атачментов *.pas в слове for первую букву меняет на заглавную 🙂
И поставить на отправку почты начальнику 🙂
Чего мучаться то :))

Nikolay M. ©
Нужно просто фильтр написать который у атачментов *.pas в слове for первую букву меняет на заглавную 🙂
И поставить на отправку почты начальнику 🙂
Чего мучаться то :))

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

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

Насчет 5$ может и сурово, но когда программист уходит, а начальник остается один на один с его кодом, то он не будет
рвать на себе волосы, а спокойно разберется.
Кстати только так и можно написать большую систему, к которой привлечено большое количество людей.
Удачное именование переменных в этом случае играет огромную роль, когда каждому челу по имени переменной понятно для чего она нужна и как ее использовать.

Насчет 5$ может и сурово, но когда программист уходит, а начальник остается один на один с его кодом, то он не будет
рвать на себе волосы, а спокойно разберется.
Кстати только так и можно написать большую систему, к которой привлечено большое количество людей.
Удачное именование переменных в этом случае играет огромную роль, когда каждому челу по имени переменной понятно для чего она нужна и как ее использовать.


> Style © (07.04.04 11:42) [20]

Ну вот еще!
Кстати, один раз наблюдал такой круговорот событий.
Начальник начал насаживать очередной «стандарт», как следствие, программист, который писал программу в едином стиле уволился (кому охота фигней страдать?), на его место пришел другой, который не сразу включился в «стандарт», после трений с начальником также уволился, начальника заменили, поскольку не может обеспечить нормальную работу, на его место приходит новый, со своим «стандартом», все начинается по новой.
Я этот процесс застал на n-дцатой итерации и имел счастье видеть ужасно кривую программу, к тому же без единого комментария. больше 2 месяцев я не выдержал.


> Style © (07.04.04 11:42) [20]

Ну вот еще!
Кстати, один раз наблюдал такой круговорот событий.
Начальник начал насаживать очередной «стандарт», как следствие, программист, который писал программу в едином стиле уволился (кому охота фигней страдать?), на его место пришел другой, который не сразу включился в «стандарт», после трений с начальником также уволился, начальника заменили, поскольку не может обеспечить нормальную работу, на его место приходит новый, со своим «стандартом», все начинается по новой.
Я этот процесс застал на n-дцатой итерации и имел счастье видеть ужасно кривую программу, к тому же без единого комментария. больше 2 месяцев я не выдержал.

бывают такие правила —
можно «закрыть» курсор мыши в таком то прямоугольнике, но использование этой функции = плохой тон

эти правила не только программистам важны:)

бывают такие правила —
можно «закрыть» курсор мыши в таком то прямоугольнике, но использование этой функции = плохой тон

эти правила не только программистам важны:)

Nikolay M. © (07.04.04 11:36)
zzet © (07.04.04 11:48)

Вы поработайте в команде над серьезным проектом, потом вернемся к разговору.

Неужели вы всерьез считаете, что Тейксейра с Пачеко, да и многие другие, пишут о том, что стандартизация кода есть хорошо, только потому, что им просто хочется поговорить или засорить мозги читателям ? :))

Nikolay M. © (07.04.04 11:36)
zzet © (07.04.04 11:48)

Вы поработайте в команде над серьезным проектом, потом вернемся к разговору.

Неужели вы всерьез считаете, что Тейксейра с Пачеко, да и многие другие, пишут о том, что стандартизация кода есть хорошо, только потому, что им просто хочется поговорить или засорить мозги читателям ? :))

Где-то была ссылка на сайт, где представлены образцы как хорошего интерфейса, так и такие, как не надо делать. Помню там перлы типа выбор пола через два чекбокса (видимо решили все варианты предусмотреть). А у нас на работе вполне реально используется такой образец того, как делать не надо — Siebel CaRDS. Это система для трекинга багов и проблем. Такого ублюдского интефейса я давно не видел.

Да, возвращаемся к теме.
Стрелял бы тех, кто не пишет комментарии.
Все, пошел вешаться.

Где-то была ссылка на сайт, где представлены образцы как хорошего интерфейса, так и такие, как не надо делать. Помню там перлы типа выбор пола через два чекбокса (видимо решили все варианты предусмотреть). А у нас на работе вполне реально используется такой образец того, как делать не надо — Siebel CaRDS. Это система для трекинга багов и проблем. Такого ублюдского интефейса я давно не видел.

Да, возвращаемся к теме.
Стрелял бы тех, кто не пишет комментарии.
Все, пошел вешаться.

>[25] Игорь Шевченко © (07.04.04 11:54)

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

>[25] Игорь Шевченко © (07.04.04 11:54)

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

Если б меня мой босс попробовал оштрафовать за то что не может прочитать мой код на 5$, я бы ему эти 5$ в *** засунул и расчитался.
(поэтому я, как начальник, никогда так не поступаю)

Если б меня мой босс попробовал оштрафовать за то что не может прочитать мой код на 5$, я бы ему эти 5$ в *** засунул и расчитался.
(поэтому я, как начальник, никогда так не поступаю)

Alex Konshin © (07.04.04 11:59)

Alex Konshin © (07.04.04 11:59)

Насчет понимающих команд: я сам свой код после трех месяцев перерыва разбираю как чужой — ни хрена не помню. Занятно, бывает, сделать открытие в своей же собственной программе. Другому же человеку во много раз труднее. Так что я не верю в понимающие команды. Нужно просто писать так, что было понятно.

Насчет понимающих команд: я сам свой код после трех месяцев перерыва разбираю как чужой — ни хрена не помню. Занятно, бывает, сделать открытие в своей же собственной программе. Другому же человеку во много раз труднее. Так что я не верю в понимающие команды. Нужно просто писать так, что было понятно.

Вот напрмер пример моего кода, говорят тяжелый, а я так не думаю:)

function ReadCarrentSid(var UserInfo:TUserVariables):boolean;
Var Username:String;
var CUsername:longword;
Var TSid,Sid:PSID;
var Csid:longword;
var Domain:String;
Var Cdomain:longword;
Var PUse:SID_NAME_USE;
Var BlobStream:TStream;
var i:integer;
var found:boolean;
begin
//получаем текущий SID пользователя
CUsername:=0;
GetUserName(nil,CUsername);
SetLength(Username,CUsername);
GetUserName(@Username[1],CUsername);
//
Cs > LookupAccountName(nil,@Username[1],nil,Csid,nil,Cdomain,PUse);
SetLength(Domain,cDomain);
GetMem(SID,cSID);
LookupAccountName(nil,@Username[1],Sid,Csid,@Domain[1],Cdomain,PUse);
//создаем запрос на пользователя
MainData.UserQuery.Active:=false;
MainData.UserQuery.SQL.Clear;

MainData.UserQuery.SQL.Add(«select * from faxusers;»);
MainData.UserQuery.Active:=True;
//ищем нужный SID
found:=False;
MainData.UserQuery.first;
if (MainData.UserQuery.RecordCount>0) then
begin
while (not MainData.UserQuery.Eof) and (found=false) do
begin
BlobStream:=MainData.UserQuery.CreateBlobStream(MainData.UserQuery.FieldByName(«winsid»),bmRead);
if BlobStream.Size=CSid then
begin
found:=True;
GetMem(TSid,BlobStream.Size);
BlobStream.ReadBuffer(PByteArray(TSid)[0],BlobStream.Size);
for i:=0 to Csid-1 do
if (PByteArray(Sid)[i]<>PByteArray(TS > FreeMem(TSid);
end;
BlobStream.Free;
if found=false then MainData.UserQuery.Next;
end;
end;

//получам данные если запрос с данной информацией найден
if (found=True) then
begin
UserInfo.LOGIN:=MainData.UserQuery.FieldByName(«LOGIN»).AsString;
UserInfo.USERNAME:=MainData.UserQuery.FieldByName(«USERNAME»).AsString;
UserInfo.CANDELETEFAX:=MainData.UserQuery.FieldByName(«CANDELETEFAX»).AsInteger;
UserInfo.IMMORTAL:=MainData.UserQuery.FieldByName(«IMMORTAL»).AsInteger;
UserInfo.CANGETFAX:=MainData.UserQuery.FieldByName(«CANGETFAX»).AsInteger;
UserInfo.ADMINISTRATOR:=MainData.UserQuery.FieldByName(«ADMINISTRATOR»).AsInteger;
//
ReadCarrentS > end
else
ReadCarrentS > //
Username:=»»;
Domain:=»»;
FreeMem(Sid);
//закрываем запрос
MainData.UserQuery.Active:=false;
MainData.UserQuery.SQL.Clear;
end;

Вот напрмер пример моего кода, говорят тяжелый, а я так не думаю:)

function ReadCarrentSid(var UserInfo:TUserVariables):boolean;
Var Username:String;
var CUsername:longword;
Var TSid,Sid:PSID;
var Csid:longword;
var Domain:String;
Var Cdomain:longword;
Var PUse:SID_NAME_USE;
Var BlobStream:TStream;
var i:integer;
var found:boolean;
begin
//получаем текущий SID пользователя
CUsername:=0;
GetUserName(nil,CUsername);
SetLength(Username,CUsername);
GetUserName(@Username[1],CUsername);
//
Cs > LookupAccountName(nil,@Username[1],nil,Csid,nil,Cdomain,PUse);
SetLength(Domain,cDomain);
GetMem(SID,cSID);
LookupAccountName(nil,@Username[1],Sid,Csid,@Domain[1],Cdomain,PUse);
//создаем запрос на пользователя
MainData.UserQuery.Active:=false;
MainData.UserQuery.SQL.Clear;

MainData.UserQuery.SQL.Add(«select * from faxusers;»);
MainData.UserQuery.Active:=True;
//ищем нужный SID
found:=False;
MainData.UserQuery.first;
if (MainData.UserQuery.RecordCount>0) then
begin
while (not MainData.UserQuery.Eof) and (found=false) do
begin
BlobStream:=MainData.UserQuery.CreateBlobStream(MainData.UserQuery.FieldByName(«winsid»),bmRead);
if BlobStream.Size=CSid then
begin
found:=True;
GetMem(TSid,BlobStream.Size);
BlobStream.ReadBuffer(PByteArray(TSid)[0],BlobStream.Size);
for i:=0 to Csid-1 do
if (PByteArray(Sid)[i]<>PByteArray(TS > FreeMem(TSid);
end;
BlobStream.Free;
if found=false then MainData.UserQuery.Next;
end;
end;

//получам данные если запрос с данной информацией найден
if (found=True) then
begin
UserInfo.LOGIN:=MainData.UserQuery.FieldByName(«LOGIN»).AsString;
UserInfo.USERNAME:=MainData.UserQuery.FieldByName(«USERNAME»).AsString;
UserInfo.CANDELETEFAX:=MainData.UserQuery.FieldByName(«CANDELETEFAX»).AsInteger;
UserInfo.IMMORTAL:=MainData.UserQuery.FieldByName(«IMMORTAL»).AsInteger;
UserInfo.CANGETFAX:=MainData.UserQuery.FieldByName(«CANGETFAX»).AsInteger;
UserInfo.ADMINISTRATOR:=MainData.UserQuery.FieldByName(«ADMINISTRATOR»).AsInteger;
//
ReadCarrentS > end
else
ReadCarrentS > //
Username:=»»;
Domain:=»»;
FreeMem(Sid);
//закрываем запрос
MainData.UserQuery.Active:=false;
MainData.UserQuery.SQL.Clear;
end;

SoftX (07.04.04 12:06)

SoftX (07.04.04 12:06)

Можно и утилитку написать

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

Кстати может кто напишет? Что скажите Мастера?

Можно и утилитку написать

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

Кстати может кто напишет? Что скажите Мастера?

>SoftX (07.04.04 12:06) [31]
Мдя. С самого начала все ясно: ReadCarrentSid.

>SoftX (07.04.04 12:06) [31]
Мдя. С самого начала все ясно: ReadCarrentSid.

Игорь Шевченко © (07.04.04 12:04) [29]
Alex Konshin © (07.04.04 11:59)
https://www.akzhan.midi.ru/iarchitect/ ?

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

Игорь Шевченко © (07.04.04 12:04) [29]
Alex Konshin © (07.04.04 11:59)
https://www.akzhan.midi.ru/iarchitect/ ?

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

Паниковский © (07.04.04 12:09)


> Можно и утилитку написать


> Кстати может кто напишет?

Паниковский © (07.04.04 12:09)


> Можно и утилитку написать


> Кстати может кто напишет?

>Паниковский © (07.04.04 12:09) [33]
Ничего себе загнул:)
из строк
Var i:integer;
moyaperemennaja:String;
begin
i:=1;moyaperemennaja:=»раз»;
end; мне надо получить:

var
I: Integer;
Str: string;
begin
I := 1;
Str := «Раз»;
end;

Есть предложения какие ключевые слова использовать?

>Паниковский © (07.04.04 12:09) [33]
Ничего себе загнул:)
из строк
Var i:integer;
moyaperemennaja:String;
begin
i:=1;moyaperemennaja:=»раз»;
end; мне надо получить:

var
I: Integer;
Str: string;
begin
I := 1;
Str := «Раз»;
end;

Есть предложения какие ключевые слова использовать?

Давайте будем честны: правильное форматирование исходного текста := лучшее понимание собою же написанного. Бывает, понавалишь там временно всякого барахла, потом сам не поймешь, зачем так всего и много. А чтобы прочитать все это можно было — хотя бы тот же банальный 2 пробела перед begin поставить-таки следует.
Руководство просто вероломствует и самодурит по причине своей, порой, малограмотности и недостатка образования.

Давайте будем честны: правильное форматирование исходного текста := лучшее понимание собою же написанного. Бывает, понавалишь там временно всякого барахла, потом сам не поймешь, зачем так всего и много. А чтобы прочитать все это можно было — хотя бы тот же банальный 2 пробела перед begin поставить-таки следует.
Руководство просто вероломствует и самодурит по причине своей, порой, малограмотности и недостатка образования.


> zzet © (07.04.04 12:03) [28]
> Если б меня мой босс попробовал оштрафовать за то что не
> может прочитать мой код на 5$, я бы ему эти 5$ в *** засунул
> и расчитался.

Аналогично.


> zzet © (07.04.04 12:03) [28]
> Если б меня мой босс попробовал оштрафовать за то что не
> может прочитать мой код на 5$, я бы ему эти 5$ в *** засунул
> и расчитался.

Аналогично.

> [32] Игорь Шевченко © (07.04.04 12:09)
> Справедливо говорят.

Не в плане спора, а из любопытства: приведите свой.

> [32] Игорь Шевченко © (07.04.04 12:09)
> Справедливо говорят.

Не в плане спора, а из любопытства: приведите свой.

Добавить комментарий