Программистские ошибки для чайников

COTOHA
Опубликовано 15.10.2008 в Разработка, Учеба

Конспект лекции “Типичные ошибки начинающих программистов”, прочитанной в ИНЖЕКе 29 сентября 2008 года. Думаю, будет полезна и всем остальным студентам… а может и не только.

Вступление

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

О лекторе

Для начала обо мне. Я (как вам, наверное, уже должны были сказать) работаю в компании NIX Solutions Ltd. на должности директора по обучению и развитию персонала. Кроме того я успел поработать php-разработчиком, менеджером отдела продаж, начальником отдела продаж, менеджером проектов, начальником отдела php и начальником отдела .net. Это чтобы вы понимали, что эта моя лекция про ошибки начинающих программистов, которую меня попросили вам прочитать, не просто теория очередного менеджера о том, что должны делать идеальные программисты. Всё что я расскажу — суровая правда жизни. Я сам совершал многие из этих ошибок, и я постоянно вижу, как их совершают новички у нас на фирме.

Мотивация

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

Про ошибки

Ошибок, которые совершают начинающие программисты, очень-очень много. Чтобы не перечислять их все (на что не хватит времени), я решил попытаться их сгруппировать и рассмотреть наиболее типичные группы.

Ошибки

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

Детские

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

Невнимание к деталям. Едва ли не основным признаком профессионала является внимание к деталям. В профессиональном приложении вы никогда не увидите ничего из ниже перечисленного:
- Недоформатирование текстов/Недовыравнивание элементов форм. Куски лейбочек, который вылезают за панели; кнопки, которые перекрывают лейбы; тексты, которые уползают за край формы.
- Отсутствие единообразия в интерфейсе, форматировании тектов, расположении форм. Это тот случай, когда лучше «безобразно, но единообразно». Это же, кстати, отличает айтишников от всех остальных при использовании MS Word: айтишники используют стили, и потом могут легко менять вид документа, изменяя стили, а остальные каждый элемент форматируют вручную и при необходимости изменить вид заголовка второго уровня переформатировывают все заголовки 2го уровня в доке.
- Неучитывание возможности изменения размеров формы. Самый обычный вариант тут — просто забыть о том, что формы могут меняться, забыть установить значения минимальной и максимальной ширины и высоты. Самый некрасивый и неюзабельный — задать абсолютную привязку ко всем сторонам формы, так что контролы наедут друг на друга при её увеличении. Также часто забывают запретить “распахивать” окно, хотя запрещают “ресайз”.
- Использование названий контролов, которые за вас придумала IDE. Button1, Form2, открытьИзображениеToolStripMenuItem_Click. Этого делать нельзя, т.к. радикально ухудшает читабельность кода, а значит увеличивает стоимость его поддержки. Вообще «неговорящие» названия контролов плохо. Говорящие по-русски — спорно, т.к. часто вы будете писать приложения для заграничных заказчиков, а это означает, что русские названия методов не пройдёт процедуру приёмки исходного кода.
- Сортировка числовых значений по правилам строк. Это часто происходит, когда значения хранятся в виде цифр (15.45), а отображаются в строковом виде (15грн.45коп.). И сортировки выполняются средствами стандартных компонентов. Надо это учитывать и реализовывать сортировки как надо.
Смешение парадигм процедурного и объектно-ориентированного программирования. К сожалению, на собеседованиях я очень редко встречаю претендентов, которые бы могли внятно объяснить, чем ООП лучшее. Более того — мало кто может сказать, лучше чем что. Естественно, что не понимая, зачем ООП нужно, оно применяется неправильно.
- Применение ООП для отмазки. Чем применять ООП «для галочки», лучше его не применять вообще, т.к. с одной стороны выглядят эти попытки жалко, а с другой запутывают ваших товарищей, которые ожидают «правильного» использования ООП, раз уж оно вообще использовано.
- Использование «глобальных переменных». Особенно в виде «Form1.condition». Это снижает читабельность кода и является симптомом того, что вы неправильно спроектировали приложение.
- Использование статических методов, для решения бизнес-задачи. Если у вашего класса есть только поведение (методы), но нет свойств (полей), значит, вы неправильно провели анализ предметной области (не всегда, но чаще всего).
Неправильные комментарии. Комментарии — это отличный помощник, если их использовать по назначению. Многие игнорируют этот факт.
- Не писать вообще. Cowboy-style. Хорошо, что преподаватели стараются с этим бороться… и порождают следующую проблему.
- Писать очевидные комментарии. Когда что-то делается из-под палки, это всегда делается плохо. Так и тут — особенно умиляют комментарии вида «int a; // объявляем переменную». Выглядит как издёвка (особенно, если через две строчки следует алгоритм без единого комментария с кучей циклов, ифов, break’ов и с несколькими return’ами), а издеваться над сотрудниками (и преподавателями) мало того, что нехорошо, так ещё и чревато.
- Не описывать метод/класс. С этим старается бороться IDE. Не надо ей мешать — она знает, что делает. Автодоки сохраняют время всей команде и вам лично, когда приходит время писать документацию на проект.
Неследование code conventions. Стандарты кодирования позволяют вам разобраться в чужом коде (или кому-то в вашем) намного быстрее и легче. Обычно программисты подсознательно следуют какому-то одному стилю, но встречаются и такие у которых 7 пятниц на неделе. В любом случае, я советую явно выбрать подходящий стиль и стараться ему следовать. По умолчанию можно использовать стандарты кодирования pear для php, sun для java и Microsoft для семейства .net.
- Хаотичное форматирование кода. Самый клинический случай, это когда у одного и того же человека разные куски кода отличаются по форматированию. Некоторые даже говорят, что это признак маниакально-депрессивного психоза. Ну или ему просто курсовик помогали писать соседи по общаге
- Каждый член команды использует удобную ему конвенцию. Это менее плохо, но тоже не хорошо. Для работы в команде просто необходимо принять общий стандарт кодирования, иначе это будет не работа в команде, а просто работа над одним проектом.

Детские ошибки можно перечислять и перечислять, но я ограничился только теми ошибками, которые я встретил в ваших работах больше 3х раз.

Тактические

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

Не иметь правильной цели для проекта. Первой и главной целью при написании курсовых, лаб и дипломов необходимо ставить «поднять свой уровень», а не «отмазаться от преподавателя». Подумайте, ведь в большинстве случаев, когда вы придёте на собеседование, эти программы будут единственным, чем вы сможете похвастаться — может стоить сделать их хорошо?
И так сойдёт. Отсутствие правильно цели приводит к тому, что программы делаются «тяп-ляп», как у зайца в старом мультике (все помнят?). В двух словах — на пользу это ему не пошло. Можно выделить несколько подпунктов:
- Размещение бизнес-логики в обработчиках событий. Это наверное самая распространённая ошибка, которую совершают абсолютно все. Можем провести эксперимент — пусть честные люди поднимут руки, если они помещали решение задачи в какой-нибудь «onClick». Я так и думал… честных людей мало Чтобы побороть эту ошибку есть теоретически простой, но сложный в реализации метод… но полезный: сначала нужно написать консольное приложение, а потом докрутить к нему GUI.
- Тестирования приложения только на допустимых значениях. Удивительно, как много приложений падает, как только ввести в поле для ввода цифр буквы. Когда вы пишете приложение, необходимо рассчитывать не на дружеского пользователя, а на агрессивную обезьяну, которая может ввести что угодно и нажать куда угодно. Приложение должно на всё реагировать корректно.
- Хардкод. Внесение конфигурационных параметров, строковых литералов, магических цифр в код — это плохо. Для этого давным-давно придуманы специальные средства — конфигурационные файлы, файлы ресурсов, формы настроек. По возможности необходимо избегать перекомпиляции приложения, для его настройки, т.к. в реальном мире, за перекомпиляцией следует фаза развёртывания, а это очень дорого.
- Копи-паст. Дублирование кода увеличивает стоимость его поддержки — ведь в любом коде будут производится изменения, это данность. От этого никуда деться нельзя, а значит надо будет вместо одного изменения производить много (в зависимости от количества скопированных кусков) и ещё и синхронизировать их. За правило надо взять принцип, что если какой-то кусок кода понадобился больше двух раз, то его надо выделить в метод, класс или модуль.
- Плохой русский/украинский/английский в сопроводительной документации. Документация — это неотъемлемая часть проекта. Если документацию неприятно читать, то это отношение распространится на весь проект в целом. Что я имею в виду? Например, откровенные глупости в части про БЖД, которые кочуют из записки в записку. (Я уже говорил, что копи-паст это плохо? на документацию это тоже распространяется). Или излишне вольное обращение с украинским языком, например «разрешение монитора», это «роздільна здатніcть», а не «дозвіл», как практически у всех вас в записках.
Несоответствие результата и цели. Если реализовывать что-то “тяп-ляп”, то и результат получается посредственный. Любая программа решает некую бизнес задачу — вот реализация этой бизнес-задачи и есть цель вашего проекта, а значит и результат должен быть этой же реализацией. Например, если вам дали курсовой на тему «однопользовательская игра с графическим интерфейсом», то вам надо сконцентрироваться на игре, на её динамике, на удобстве интерфейса, на функциях, характерных для игр — тогда в результате у вас будет (сюрприз!) интересная однопользовательская игра. Но в большинстве случаев студенты концентрируются на том, чтобы просто сдать курсач. В итоге получается скучная игра, которой неудобно пользоваться, обёрнутая в стандартный для windows-приложений интерфейс — стандартный проект-отмазка. Это не правильно. В первую очередь надо решить поставленную задачу — это позволит вам повысить свой уровень в программировании и анализе, и как приятный побочный эффект позволит вам получить высокую оценку за неё.
- Недостаточная проработка теоретической части проекта. Очень часто встречаются проекты, в которых не понятна задача, которую они решают. Не секрет, что большинство студенческих проектов — это некие интерфейсы к базам данных. Например, учёт книг в библиотеке, учёт шахт на Украине, учёт студентов в деканате. Это разные цели. А результат у всех один и тот же - они, по сути, они как братья близнецы — формы редактирования, поиска и добавления новых записей. ЭТО НЕ ИНТЕРЕСНО. И это не правильно. Если вы хотите добавить интереса в ваш проект, то опишите, какие насущные задачи решает проект, какие реальные процессы он автоматизирует. Не зацикливайтесь на добавлении и редактировании записей — ведь в большинстве случаев руками никто ничего добавлять не будет, т.к. базы данных уже есть и их надо просто импортировать. Редактирование не такой частый процесс — разве что кто-то выйдет замуж и сменит фамилию (если говорить про учёт студентов). Сконцентрируйтесь на правах доступа, на вариантах поиска, на том, что реально нужно. Сходите в деканат и спросите — чего нужно его работникам. Это зачтётся.
Обман. Да самый обычный обман пользователей (в частном случае преподавателей).
- Если в приложении заявлена некая функциональность, то её или надо реализовать в соответствии с требованиями или в сопровождающей документации указать на ограниченность реализации. Последний пример, который приходит на ум это «экспорт в формате MS Excel». Один из ваших товарищей реализовал это в виде генерации файла значений, разделённых пробелом, которому назначалось расширение XLS. Эксель, конечно, его открывал и автоматически распарсивал, но по сути это был обман, т.к. другие офисные системы, которые читают формат XLS, его уже не понимали. Обман производит дурное впечатление, хотя одна всего лишь фраза в документации о том, что эта функция реализована в ограниченном объёме могла бы всё исправить.
- Не использовать/неправильно использовать ООП в курсовом по предмету “объекто-ориентированное программирование” — это тоже обман.
- покупать лабы/курсовые/дипломы — это тоже обман. Хорошо, если вы не собираетесь становиться программистом — тогда вы обманываете только преподавателя. Но если у вас есть такие планы, то вы обманываете ещё и себя.

Стратегические

Стратегические ошибки — это ошибки стиля жизни. Они связаны с долгосрочными целями или — чаще — с их отсутствием

Не знать, кем и почему вы хотите стать. Это основная ошибка студентов. Они думают, что до окончания ВУЗа, этот вопрос ещё не актуален. А на самом деле потом, а может быть уже и сейчас, будет поздно. Первый вопрос, который я задаю на собеседованиях: «Почему ты решил стать программистом / тестировщиком / аналитиком?» И с грустью не слышу ничего вразумительного в ответ. Это важно прежде всего для вас — если вы НЕ понимаете, почему вы хотите стать программистом, то может быть вы вовсе и не хотите им становиться? Может вы модельер, а тут только тратите своё время? Подумайте…
Не пытаться улучшить свой скил в программировании. Второй вопрос на собеседовании, который я задаю всем: «Что ты делаешь, чтобы стать тем, кем ты хочешь стать?» Опять же очень не часто, мне могут ответить что-то кроме «учусь на соответствующей специальности». Этого мало.
- Не читать книг по теме. Мне это странно, но не многие читают книги, а надо — там много полезного. Кто сходу может назвать автора какой-нибудь книги по .NET? А ещё одного? А третьего? На первый вопрос ответило 10 человек из 60, на второй 3, а на третий ни одного…
- Не писать программ, помимо лаб, курсовых и дипломов. Это мне странно больше всего. Если вы хотите стать программистом, то почему не пишете программ? На собеседованиях некоторые на вопрос “почему программирование?” задумываются и говорят что-то вроде: “я люблю творить”. Так почему не творишь? Ну да, я понимаю, что конъюнктура рынка сейчас такая, что ай-ти-специальности популярны и многие идут туда ради приличного заработка, а не тварьбы. Но тогда возникает вопрос — почему вы не выполняете курсовые и дипломы качественно и профессионально? Ведь чем вы лучше себя покажете на собеседовании, тем лучше вам предложат стартовые условия.
- Не следить за новостями в мире выбранной технологии. Я про новости с основных сайтов по технологиям, про блоги ведущих разработчиков, про новые книги и т.д. В ВУЗе вам просто физически не могут дать мейнстрим. Вам надо понять, что вас обучают не программировании на сишарпе, а программировать на примере сишарпа. Это значит, что вам никто не мешает использовать .NET Framework 3.5, LINQ и Entity Framework, хотя и не заставляют. Это ваш выбор — надо только не лениться его сделать.
- Не проходить различные программы сертификации. Это момент конечно спорный, т.к. они денег стоят, но они окупаются. Кроме того, вам же всё равно надо учить .net, java или php, так почему бы не поучить по специальной литературе, по подготовке к сертификациям?
Не знать английского. Это вообще не обсуждается: хочешь работать в ай-ти — надо знать английский. Английский сейчас де-факто стандарт в ай-ти. Помимо того, что основная масса продуктов разрабатывается для англоязычных стран, есть ещё очень важная причина: документации к продуктам/API на неанглийском не существует. Её так мало, что ей реально можно пренебречь. А так что есть, отстаёт от английской версии на полгода минимум.

А теперь самое важное

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

Заключение

Я не питаю надежды, что раскрыл вам глаза на что-то новое. Всё что я рассказал — это здравый смысл и не более того, но теперь вы уже не сможете на собеседовании сказать «а я не знал, что так надо» В общем и целом, я хотел бы вас поблагодарить за то, что присутствовали на этой сумбурной лекции, и пожелать в первую очередь целеустремлённости, а во вторую — удачи.

Примечания

По ходу лекции больше всех записывал завкафедрой. И много кивал.
На вопрос про “логику в обработчиках onClick” руку не поднял не один. Мучаюсь теперь вопросом — а может надо было спросить “кто знает, что такое обработчики событий onClick?”
Из авторов вспомнили только Троелсена и Сеппу, то есть вообще-то одного, т.к. Сеппа по ADO книгу написал, а не по .NET. Шилдт и Рихтер видимо из моды вышли…

COTOHA,
Сентябрь 2008

Теги: ошибки, работа, учёба

(118 голосов, средний: 4 из 5)

Загрузка ...

Распределение голосов

Понравилась статья? Подпишись на обновления по RSS/E-mail

Все комментарии (141) к “Программистские ошибки для чайников”

Denis Osetrov говорит: 15.10.2008 в 09:35
Хорошая книжка для джунов, да и для самоконтроля :-). Автору ревьюва +5.
Сергей Волошин говорит: 15.10.2008 в 09:37
2Denis Osetrov:

Автору ревьюва +5.

Это делается через звездочки:
http://www.developers.org.ua/archives/cotoha/2008/10/15/programmers-mistakes-for-dummies/#ratings
Denis Osetrov говорит: 15.10.2008 в 09:45
Ага, спасибо. Профтыкал маленька.
Всеволод Соловьёв говорит: 15.10.2008 в 10:22
И это статья для ДОУ? 1

Плохой русский\украинский\английский в сопроводительной документации.

А что насчёт плохого русского/украинского/английского в статье?
COTOHA говорит: 15.10.2008 в 11:23
2 Всеволод Соловьёв
по-конкретнее пожалуйста.
dalv говорит: 15.10.2008 в 11:47
Смешение парадигм процедурного и объектно-ориентированного программирования.

Тоесть std::sort и прочее содержимое std::algorithm явно придумано криворукими студентами? Нужно было сделать класс Sorter с одним статическим методом sort? Или с конструктором который будет получать 2 итератора и метод execute без параметров?

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

Детский сад. А может Вы мне внятно объяните, чем ООП лучше? Как по мне очередная парадигма, которая на данный момент оверюсед из-за маркетингового хайпа, раздутого вокруг нее. Очень удобна для моделирования, но преподносится сейчас как “серебряная пуля”. Приписываю автору чтение Execution in the Kingdom of Nouns до полного просветления.

Не читать книг по теме. Мне это странно, но не многие читают книги, а надо — там много полезного. Кто сходу может назвать автора какой-нибудь книги по .NET? А ещё одного? А третьего? На первый вопрос ответило 10 человек из 60, на второй 3, а на третий ни одного…

Вы правда считаете, что книги по ЕтЭназерООПЛангведжВизЦЛайкСинтэкс это самое важное для будущего программиста? Это в ПТУ такому учат? Для программиста освоить очередной язычек в рамках уже известной парадигмы - дело 2х недель. Учить нужно фундаментальные вещи.
Сергей Щетинин говорит: 15.10.2008 в 11:59
>> А что насчёт плохого русского/украинского/английского в статье?
> по-конкретнее пожалуйста.
ыыыыы

Как лекция для студентов по-моему хорошо. Но по ряду причин статье поставил 2/5.
zwitter говорит: 15.10.2008 в 12:11
не могу назвать ничего из вышеперечисленного ошибками.
bialix говорит: 15.10.2008 в 12:14
что такое “БЖД”?
zwitter говорит: 15.10.2008 в 12:15
Безопасность ЖизнеДеятельности
Всеволод Соловьёв говорит: 15.10.2008 в 12:28
2СОТОНА
По поводу плохого русского - вычитывать всё лень, но очень заметны многочисленные ошибки с -тся/-ться. Ещё пример на виду - “поконкретнее” пишется слитно, без дефисов. Слэши в перечислениях не в ту сторону.

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

Прозвучало вот ещё мнение во время краткого обсуждение статьи:

Это статья для сайта delphi-lovers.ru, но никак не для DOU
Сергей Волошин говорит: 15.10.2008 в 13:55
Слэши в перечислениях не в ту сторону.

Перевернул.

но очень заметны многочисленные ошибки с -тся/-ться

Сходу не нашёл (ни одного случая), был бы благодарен, если кто-то ткнёт носом.
Всеволод Соловьёв говорит: 15.10.2008 в 14:31
Например:

если вы НЕ понимаете, почему вы хотите стать программистом, то может быть вы вовсе и не хотите им становится
COTOHA говорит: 15.10.2008 в 14:54
2 dalv

Тоесть std::sort и прочее содержимое std::algorithm явно придумано криворукими студентами? Нужно было сделать класс Sorter с одним статическим методом sort? Или с конструктором который будет получать 2 итератора и метод execute без параметров?

внимательнее читаем: значит, вы неправильно провели анализ предметной области (не всегда, но чаще всего).
и кстати std используется не как класс, а как неймспейс. и, если мне память не изменяет - давно это было, это и есть namespace.

Детский сад. А может Вы мне внятно объяните, чем ООП лучше? Как по мне очередная парадигма, которая на данный момент оверюсед из-за маркетингового хайпа, раздутого вокруг нее. Очень удобна для моделирования, но преподносится сейчас как “серебряная пуля”. Приписываю автору чтение Execution in the Kingdom of Nouns до полного просветления.

лучше чем что? я нигде не говорю, что это серебрянная пуля и статью эту читал года 2 назад. кстати там есть с чем спорить но в данном конкретном случае я говорю о том, что если ты уже УЧИШЬ ООП, то учи, а не отмазывайся. или приведи на собеседовании веские причины, почему его учить не надо.

Вы правда считаете, что книги по ЕтЭназерООПЛангведжВизЦЛайкСинтэкс это самое важное для будущего программиста? Это в ПТУ такому учат? Для программиста освоить очередной язычек в рамках уже известной парадигмы - дело 2х недель. Учить нужно фундаментальные вещи.

если бы я попросил назвать автора какой-то книги по архитектуре приложений или по жизненному циклу ПО, то рук не было бы вообще. так что не цепляйтесь к словам, а просто скажите - книги по теме читать надо?
COTOHA говорит: 15.10.2008 в 14:56
2 Сергей Щетинин

Как лекция для студентов по-моему хорошо. Но по ряду причин статье поставил 2/5.

причины типа “этой статье не место на ДОУ”? или что-то другое?
COTOHA говорит: 15.10.2008 в 14:57
2 zwitter

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

омг. оригинально. совсем-совсем ничего?
zwitter говорит: 15.10.2008 в 15:00
именно. это скорее стиль программирования, дизайн.
скорее всего программа, написанная с указанными “ошибками” - будет работать
ведь согласитесь, хардкод и копипаст - не баги в классическом понимании.
программистская ошибка для чайников - это например
delete p;
…
if(p == NULL) …
COTOHA говорит: 15.10.2008 в 15:01
2 Всеволод Соловьёв

По поводу плохого русского - вычитывать всё лень, но очень заметны многочисленные ошибки с -тся/-ться. Ещё пример на виду - “поконкретнее” пишется слитно, без дефисов. Слэши в перечислениях не в ту сторону.

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

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

вот это уже очень интересно. что именно противоречит здравому смыслу? мне важно знать ответ, т.к. лекция-то не последняя - надо исправляться.
COTOHA говорит: 15.10.2008 в 15:03
2 zwitter

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

а в этом плане… ну с такой точкой зрения соглашусь.
только тут надо просто различать ошибки программы (ака баги) и ошибки программиста (вот то, что я написал)
zwitter говорит: 15.10.2008 в 15:08
все равно не согласен с тем, что это “ошибки”.
это просто “путь” нерадивого “специалиста”.
а естественный отбор расставит все по своим местам.
dalv говорит: 15.10.2008 в 15:35
внимательнее читаем: значит, вы неправильно провели анализ предметной области (не всегда, но чаще всего).

Так и запишем: Степанов не асилил книжку “для чайников” и поэтому неправельно провел анализ предметной области.

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

Тоесть вы хотите что-бы в вузах помимо Троельсена и Шилдта еще ГоФ и МакКонела учили? о_О

так что не цепляйтесь к словам, а просто скажите - книги по теме читать надо?

Надо, но конкретно те, которые Вы предалагаете скорее годятся для ПТУ.
Сергей Щетинин говорит: 15.10.2008 в 15:37
причины типа “этой статье не место на ДОУ”? или что-то другое?

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

скажите - книги по теме читать надо?

Вроде как и надо. Только вот попробовал вспомнить какие сам читал и всплыло только пять названий типа “Основы Turbo Pascal 7.0″, “Borland C++ какой-то там” да “Delphi 2.0 Unleashed” (допускаю что забыл еще несколько). Классной была только одна — по ассемблеру, автор российский еще Забыл Какзовут, кстати знания оттуда никогда на деле не применял. И доступа к инету не было, т.е. чтением онлайн не компенсировалось. А вот автора вообще ни одного, ни на какую технологию не назову. Зато есть знакомые с такими библиотеками, что мама-дорогая, правда уровень нулевой даже спустя годы.

Насчет ошибок еще “не соответствие”, “не следование” итп которые пишутся слитно. См.
COTOHA говорит: 15.10.2008 в 15:39
2 zwitter
:) ну да - если человек планирует стать нерадивым специалистом, то это не ошибки, а успехи. но если он хочет стать хорошим, то это ошибки. нет?
manuna говорит: 15.10.2008 в 15:41
2zwitter: имхо, “путь” нерадивого “специалиста” == “ошибка в ДНК”(с)
Сергей Щетинин говорит: 15.10.2008 в 15:45
А да, еще недурно бы писать предложения с большой буквы, уважение к читающим и всё такое.
COTOHA говорит: 15.10.2008 в 16:00
2 Сергей Щетинин

Вроде как и надо. Только вот попробовал вспомнить какие сам читал и всплыло только пять названий типа “Основы Turbo Pascal 7.0″, “Borland C++ какой-то там” да “Delphi 2.0 Unleashed” (допускаю что забыл еще несколько). Классной была только одна — по ассемблеру, автор российский еще Забыл Какзовут, кстати знания оттуда никогда на деле не применял. И доступа к инету не было, т.е. чтением онлайн не компенсировалось. А вот автора вообще ни одного, ни на какую технологию не назову. А есть знакомые с такими библиотеками, что мама-дорогая, а уровень увы нулевой, даже спустя годы.

согласен. тут надо было бы спросить не имя автора, а просто “кто прочитал за последние полгода 1 книгу по специальности, а 2, а 3?”
COTOHA говорит: 15.10.2008 в 16:02
2 manuna

2zwitter: имхо, “путь” нерадивого “специалиста” == “ошибка в ДНК”(с)

изначально строчка “Стратегические ошибки — это ошибки стиля жизни” звучала как “Стратегические ошибки — это ошибки ДНК”, но я исправил
Сергей Волошин говорит: 15.10.2008 в 16:04
А мне понравилось слово “тварьбы”.
Сергей Щетинин говорит: 15.10.2008 в 16:10
тут надо было бы спросить не имя автора, а просто “кто прочитал за последние полгода 1 книгу по специальности, а 2, а 3?”

Я за последние пять лет вроде прочитал ноль. Я то не студент, но всё равно критерий так себе. Если шесть програмерских книг в год глотать, когда учиться програмить? =)
COTOHA говорит: 15.10.2008 в 16:16
2 Сергей Щетинин

Я за последние пять лет вроде прочитал ноль. Я то не студент, но всё равно критерий так себе. Если шесть програмерских книг в год глотать, когда учиться програмить? =)

ну… тебе пора писать по питону книгу так что извинительно. книги можно заменить на “статьи”, “блоги” - вобщем я сужу по собеседованиям. Так вот студенты в большинстве НИЧЕГО не читают. потому и спросил… надеялся их пронять.
Старовойт Михаил говорит: 15.10.2008 в 16:49
Полезная статья, скопировал себе в блог, линк из статьи не прибил, оставил по-честному. Почему-то люди просят удалить пост из блога.

Это что? Цензура от девелоперс или новые правила ведения блогов?
eugene_n говорит: 15.10.2008 в 17:28
Это что? Цензура от девелоперс или новые правила ведения блогов?

Просто хочеться надеяться тут _девелоперс_, а не стьюдентс орг юэй

Кстати, до сегодня я рассматривал NIX как одно из возможных будущих мест работы,
но после двух криатиффов от СОТОНЫ, списал его со счетов.
Дрессируйте и дальше студентов малевать формочки под видом программирования, мало-мальски уважающему себя спецу делать у вас явно нечего.

Кстати вот и ответ на вопрос “почему мы такие аутисты”
Андрей Церкус говорит: 15.10.2008 в 17:42
Товарищи,
проясните вопрос с бизнес-логикой в обработчиках событий. Где-то видел еще упоминание, что этого лучше не делать (возможно, даже в антипаттернах). Но, если я знаю, что этот обработчик и эту логику никто никогда больше не будет использовать извне, то в каждом обработчике вызывать функцию, в которой просто нет приставки -on- для меня является бесполезной тратой компьютерного времени и разрастанием списка методов класса:
———-
function onClick() {
this.click();
}
———-

Поясните, я думаю этот момент совсем не так категоричен, как написал автор.
Сергей Волошин говорит: 15.10.2008 в 17:44
2eugene_n

Просто хочеться надеяться тут _девелоперс_, а не стьюдентс орг юэй

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

Кстати, до сегодня я рассматривал NIX как одно из возможных будущих мест работы,
но после двух криатиффов от СОТОНЫ, списал его со счетов.

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

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

родилась идея для серии статей: бесформенное программирование
COTOHA говорит: 15.10.2008 в 17:58
2 eugene_n

Кстати, до сегодня я рассматривал NIX как одно из возможных будущих мест работы,
но после двух криатиффов от СОТОНЫ, списал его со счетов.

хм. ну и отлично… тех, кто с логикой не в ладах, нам не надо

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

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

Кстати вот и ответ на вопрос “почему мы такие аутисты”

не понял шутку юмора. в чём ответ-то?
COTOHA говорит: 15.10.2008 в 18:04
2 Андрей Церкус

Товарищи,
проясните вопрос с бизнес-логикой в обработчиках событий. Где-то видел еще упоминание, что этого лучше не делать (возможно, даже в антипаттернах). Но, если я знаю, что этот обработчик и эту логику никто никогда больше не будет использовать извне, то в каждом обработчике вызывать функцию, в которой просто нет приставки -on- для меня является бесполезной тратой компьютерного времени и разрастанием списка методов класса:
———-
function onClick() {
this.click();
}
———-

Поясните, я думаю этот момент совсем не так категоричен, как написал автор.

если отвечать коротко, то “без фанатизма”, а если долго, то что это за “бизнес-логика”, которая завязана на click по кнопке? а если добавят меню, что делать будем? а если, не дай бог, надо будет принимать команды по RPC?
Сергей Волошин говорит: 15.10.2008 в 18:06
А может программисты такие аутисты, потому что их легко зацепить или ранить? Грубостью, грамматикой/орфографией, ранить не угадав их мысли, или обидеть не поняв намёков? Программисты не любят прощать ошибок и давать второй шанс. Вспомнился анекдот:

Социологи установили, что подняв с ковра нитку, которую не смог всосать пылесос, двоe из трех мужчин бросают её обратно, чтоб дать пылесосу ещё один шанс.
COTOHA говорит: 15.10.2008 в 18:16
2 Сергей Волошин

А может программисты такие аутисты, потому что их легко зацепить или ранить?

попутаны причины и следствия. а так верно - второй шанс давать не любят
Сергей Волошин говорит: 15.10.2008 в 18:51
2 Андрей Церкус:

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

Возможно в каком-нибудь скрипте на JavaScript так и будет:
```
$('#switcher-narrow').bind('click', function() {
  $('body').addClass('narrow');
});
```
а в целом это, как мне кажется, можно частично отнести к упомянутым в статье code conventions.
Александр говорит: 15.10.2008 в 18:54
1. В статье описаны не “ошибки” программы, а то что можно, скорее всего, назвать “программным этикетом”. Это как с обычным этикетом, можно со стола хватать все руками, а можно взять вилку, а где-то необходимо пользоваться набором из 12 вилок ложек и ножей, причём знать к какому блюду какой прибор использовать. Нет, насытится (поесть) можно любым способом, но в каждом из сообществ принят свой этикет - правила, скажем, оформления программ.

Для того чтобы подчеркнуть мысль приведу свой студенческий код второго или третьего курса:
```
procedure compvote(var graph:derevo);
var
i,j:word;
begin
graph.timer:=graph.timer+1;
{sending}
{first uarus}
for i:=1 to 2 do
if (graph.Work_P[1,1]=0) and (graph.Work_P[2,i]=0)
and (graph.I_P[2,i].Time0) and (graph.Free_P[1,1]=0)then
begin
graph.I_P[1,1]:=graph.I_P[2,i];
graph.Free_p[1,1]:=1;
graph.Free_p[2,i]:=1;
clearproc(graph,2,i);
end;
{second yarus}
J:=0;
repeat
for i:=1 to 2 do
if (graph.Work_P[2,1+j]=0) and (graph.Work_P[3,i+j]=0)
and (graph.I_P[3,i+j].Time0) and (graph.Free_P[2,1+j]=0)then
begin
graph.I_P[2,1+j]:=graph.I_P[3,i+j];
graph.Free_p[2,1+j]:=1;
graph.Free_p[3,i+j]:=1;
clearproc(graph,3,i+j);
end;
J:=J+2;
until j>2;
{third yarus}
J:=0;
repeat
for i:=1 to 2 do
if (graph.Work_P[3,1+j]=0) and (graph.Work_P[4,i+j]=0)
and (graph.I_P[4,i+j].Time0) and (graph.Free_P[3,1+j]=0)then
begin
graph.I_P[3,1+j]:=graph.I_P[4,i+j];
graph.Free_p[3,1+j]:=1;
graph.Free_p[4,i+j]:=1;
clearproc(graph,4,i+j);
end;
J:=J+2;
until j>6;
...
```
Код ужасен, но он работает, причём отлично работает и приложение становилось демонстрационным в институте “КАК НУЖНО ПИСАТЬ ПРОГРАММЫ”. Как вы думаете, увидев такой код, студент сможет писать программы с учётом того что их будут читать другие?

Что имеем в результате - выпускники имея кучу теоретических сведений, но не имея практических (например, в своих программах на Delphi использовал свой вариант критической секции через XCHG, так как не знал API для её стандартного использования) приходят на работу с ненужным количеством амбиций, что они типа все знают, в результате их жестоко опускают в реальный мир настоящие специалисты, которые теорию совмещают с практикой. И что мы имеем - студент после 5 лет траты денег, причём ваших денег, налогов, которые вы платите, идёт в Фокстрот и становится консультантом по ноутбукам и мобильным телефонам (тоже конечно нужная специальность, но не ценой траты многих тысяч государственных - ваших долларов на обучение).

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

Кто виноват в кадровом голоде - государственные университеты, студенты или все таки современные IT-кампании. Ну студенты вроде бы не виноваты в этом, они часто честно учатся, сдают экзамены, курсовые и лабораторные и не их вина, что в университете их не научили выпускать готовый продукт. Университеты тоже вроде бы не виноваты - они используют проверенную многими летами программу по которой училось большинство тех специалистов которые сейчас сидят на должностях IT-директоров, ПМ-ов и архитекторов. Так что проблем у системы образования нет. Можно конечно попинать IT-кампании, но они тоже вроде бы не виноваты в том, что “типа специалист” выход с которого даже отрицателен для кампании хочет за обучение прикладным навыкам ещё достойную оплату.

Вроде не виноват никто. Но основная проблема остаётся. С чем она связана - с тем что университеты выпускают не по западному образцу готового к употреблению рабочего, а архитектора без практических навыков, который он приобретал в классическом варианте трёхлетнего обучения работой “молодого специалиста”. Сейчас этого нет. Я понимаю еще мелкие кампании-стартапа которые кадры могут завлечь высокой зарплатой и прочими ухищрениями, но что думают о кадровом вопросе крупные украинские IT-корпорации, почему они не заключают с университетами договор о трёхлетнем обучении работой специалиста по необходимой им специализации, почему не лоббируют свои интересы в той же ВР?

Даже просто составить несколько небольших методичек по “интересующем технологиям”, как система контроля версий, оформления кода, какого-то дизайна страниц на php или ASP.NET и БЕСПЛАТНО(да, это прежде всего нужно работодателям для решения кадрового вопроса) распространять среди студентов профильного IT-факультета. Да. Не все из них придут вашу кампанию, но вероятность что вам можно будет найти сразу толковых джуниоров возрастёт.

PS
Всем тем кто критикует данную статью, пожелаю всегда испытывать глобальные проблемы с поиском адекватных кадров, пока вы не поймёте свою ошибку.
Сергей Волошин говорит: 15.10.2008 в 19:12
вот это уже очень интересно. что именно противоречит здравому смыслу? мне важно знать ответ, т.к. лекция-то не последняя - надо исправляться.

Одна из целей публикации этой статьи на ДОУ было не сколько научить начинающих разработчиков, но и научить (опытных разработчиков) учить начинающих разработчиков.

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

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

В статье описаны не “ошибки” программы, а то что можно, скорее всего, назвать “программным этикетом”.

Дополнение к Этике программирования Егора Егорова для студентов
Kostiantyn говорит: 15.10.2008 в 22:57
2zwriter
Невнимание к деталям - не ошибка, а неряшливость? Оригинальное у вас Дао

2dalv
Ну хотя бы SICP читать студентам надо в обязательном порядке. А про фаулеров, беков и иже с ними хотя бы рассказать, что такие есть и что они полезного понаписали
dalv говорит: 15.10.2008 в 22:59
2Kostiantyn
А Вы сами СИКП прочли и сделали все упражнения?
eugene_n говорит: 15.10.2008 в 23:16
2Сергей Волошин

хотя и доказывать своё какое-то превосходство (анонимно, хм) более приятно.

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

родилась идея для серии статей: бесформенное программирование

Смеятся после слова “лопата”?

Кстати вот и ответ на вопрос “почему мы такие аутисты”

не понял шутку юмора. в чём ответ-то?

Потому что предыдущая статья была написана на ту же аудиторию “логика-в-контроле”, а мы все сдуру начали примерять это на себя.
2 COTOHA

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

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

Малевание формочек имеет к программированию такое же отношение, как тасование видеокарт - к ремонту компьютеров. И к нам такие говноляпы не придут - хотя бы потому, что завалят на интервью подсчет битов и написание мьютекса. А я садист - могу еще и адресную арифметику подкинуть
Вообще единственное, что стоит сказать молодянку - это выкинуть “С-Шарп за 21 день” и почитать че-нибудь вечного: Кернигана-Ричи, Вирта, Кнута, ГоФ, того же Голуба в конце-концов.
2 Александр
Буквально час назад за пивом обсуждали наш молодняк. 2/3 пришли из академии “Шаг”, 1/3 электрики, электронщики, физики, химики итп. выучившиеся самостоятельно (матан сдал? годен). Выпускники профильных факультетов на интервью начинают плыть уже на ключевых словах. С какими нафиг университетами взаимодействовать??? Софтсерв, ГлобалЛоджик и другие берут себе людей с улицы и готовят как им нужно (на тоже рисование форм) и правильно делают.
Kostiantyn говорит: 15.10.2008 в 23:30
2dalv
Узнал о нем полгода назад (аж стыдно). На данный момент прочел где-то до половины, примеров сделал где-то треть. Идет очень трудно - приходится совмещать с критичным для текущих задач обучением. Но восторг от каждой страницы и примера просто щенячий. Как только появляется свободный час, возвращаюсь к прочтению.
Первые задачки решал используя drScheme, потом пересел на С#, благо достаточный инструментарий ФП в .NET 3.5 уже тоже есть.
dalv говорит: 15.10.2008 в 23:42
2Kostiantyn

На данный момент прочел где-то до половины, примеров сделал где-то треть.

Рекомендую еще видео лекции и оналайн тютор в МИТовском иКампус. Вот только примеры желательно все делать…

Первые задачки решал используя drScheme, потом пересел на С#, благо достаточный инструментарий ФП в .NET 3.5 уже тоже есть.

Жесть какая. Не удивительно что только треть примеров… Правда я давно СДиез не видел. Можно поинтересоваться как Вы например реализовали в нем ленивые списки из главы о Streams? А интерпретатор С# написали? Или все таки Схемы?
Kostiantyn говорит: 15.10.2008 в 23:45
2eugene_n
Вирт, да… его “Алгоритмы + Структуры данных” до сих пор актуальны, не смотря даже на приход ООП, возрождение ФП и почти полное вытеснение процедурного подхода.
Kostiantyn говорит: 16.10.2008 в 00:00
2davl
Я как раз к этой главе в плане прочесть подобрался. По поводу ленивых списков - в .NET для этого есть LINQ. Говорят, ленивый шо капец.
dalv говорит: 16.10.2008 в 00:05
2Kostiantyn
Каюсь, третий СДиез не видел. Гугль намекает, что LINQ - это декларативный язык запросов. Пожалуйста можно примерчик реализации с его помощью cons, car, cdr для ленивых списков. Аж самому интересно стало…
degriz говорит: 16.10.2008 в 00:06
2Александр
Я не знаю, какой универ вы заканчивали, но паскаль на 2м или на 3м курсе уже не испльзуют. B вашем коде есть избыточность =).
Я думаю, что перед тем как спрашивать про API, ООП и прочее, на собеседовании, может стоит спросить, кто такие Дональд Кнут, Никлаус Вирт и чем они знамениты.
Университет не учит, а дает знания. С каждым годом, программа урезалась и большая часть вещей давалась студенту на самоизучение, но университет закладывал фундамент, для дальнейшего саморазвития студента. Я не думаю, что преподователь не сможет ответить на вопросы, если они есть у студента.
Начсет оформления кода, когда читаешь книгу по одному из языков программирования(не ASM), то заметно, что там автор придерживается некоторого стиля. Можно задаться вопросом: почему так ?
Мне кажется, что некоторые моменты из the книги не ко всем направлениям в программировании подходят
Kostiantyn говорит: 16.10.2008 в 00:59
2dalv
Реально жесть. Есть операции объединения последовательностей (при этом получается одна общая последовательность). Операции создания пары нет. Гугл говорит, что народ таким вопросом уже задавался, но решения там я не нашел. Ппосреди ночи лезет в голову всякая чушь. Попробую завтра
jaguar говорит: 16.10.2008 в 01:27
коменты не читал, ибо представляю, шо тама могут написати. Но если представить себя не месте 17-летнего баклана, который все это слуашет в аудитории… то лекции зачем и +5.
kmmbvnr говорит: 16.10.2008 в 08:03
Можно поинтересоваться как Вы например реализовали в нем ленивые списки из главы о Streams?

В С# начиная с 2.0 есть конструкция yield return
ks говорит: 16.10.2008 в 10:42
Поставил 5 - мне понравилось…
Думается уместно переобозвать статью и обозвать - “Как нужно жить. Для Чайников.”, или “Инструкция жизни Для чайников.” - обобщив каждый пункт материала:)
Андрей Церкус говорит: 16.10.2008 в 11:24
Хорошо, “без фанатизма” мне понятно - действовать по ситуации Есть просто много мелких программ-проектов, которые никогда не будут расширяться или изменяться. Так вот для них мне кажется ненужным дублировать обработчики событий такими же методами.

Что касается JS, то там такой принцип построения обработчиков связан именно с тем, что jQuery (и другие фреймворки) по умолчанию рекомендуют не использовать ООП в полную силу, а навешивают анонимные функции в качестве обработчиков.

Еще коллеги, выскажитесь, является ли бизнес-логикой в событиях вызов штуки 4-10 методов объекта для реакции.

~примерно такое, без деталей
——
function onClick() {
values = this.fetchValues();
calced = this.calculateSmth(values);
this.saveInReport(’entered ‘ + values + ‘, calculated: ‘ + calced);
newValues = this.transmitToServer(calced);
this.redraw(newValues);
}
——

Я, лично, думаю, что такие штуки тоже лучше выносить в отдельную функцию, но с учетом размера проекта, будет ли он продолжен, а также специфического синтаксиса языка программирования.
Сергей Волошин говорит: 16.10.2008 в 11:32
2Андрей Церкус: я думаю так

Что касается JS, то там такой принцип построения обработчиков связан именно с тем, что jQuery (и другие фреймворки) по умолчанию рекомендуют не использовать ООП в полную силу, а навешивают анонимные функции в качестве обработчиков.

Мне кажется что не писать все в “onClick” - относится не только к ООП.

Просто если это действие, которое в onClick будет происходить не только по этому клику (например клику по кнопке), но и по клику по меню, тулбару, хоткею етс, то работать с текстом программы станет не так удобно. А если бы то, что в теле вашей onClick была отдельная функция (с комментариями к тому же и именем читабельным), было бы почти всегда удобнее.
Андрей Церкус говорит: 16.10.2008 в 11:42
если бы то, что в теле вашей onClick была отдельная функция (с комментариями к тому же и именем читабельным), было бы почти всегда удобнее.

Да, это понятное дело я потому и говорил - что дело не категоричное, а “почти всегда”

Если в проекте 100 обработчиков событий и другими методами эта бизнес логика не расширяется, то как-то некрасиво расширить список методов объекта до 200 просто потому, что так принято “почти всегда”
Сергей Волошин говорит: 16.10.2008 в 11:49
2Андрей Церкус: мне кажется, что к этому в принципе можно отнестись также как и к обязательному помещению блоков в {} (в C-подобных языках). Просто если _начинающего_ программиста попросить следовать каким-то правилам и при этом сказать что это только пожелание и правила действуют не всегда а почти всегда, то почти всегда разработчик будет делать как ему проще и как он привык, а если таких правил не соблюдается не 1 и не 2 то это может обернуться чем-то нехорошим.
COTOHA говорит: 16.10.2008 в 12:50
2 ks

Думается уместно переобозвать статью и обозвать - “Как нужно жить. Для Чайников.”, или “Инструкция жизни Для чайников.” - обобщив каждый пункт материала:)

“детские ошибки” не обобщаются, имхо
pako говорит: 16.10.2008 в 13:06
Использование «глобальных переменных». Особенно в виде «Form1.condition». Это снижает читабельность кода и является симптомом того, что вы неправильно спроектировали приложение.
Использование статических методов, для решения бизнес-задачи.

постоянно твердят “так низзя!!!”. но для статьи этого мало - объяснить почему так плохо или показать как правильно на практическом примере.
без этого всякие абстрактные “неправильно спроектировали” звучат как “можно, но по уставу не положено”, и польза этих запретов нулевая.
надеюсь харьковские студенты почерпнули больше, чем я.
zwitter говорит: 16.10.2008 в 13:09
кстати, автор статьи действительно считает, что Form1.Condition - глобальная переменная ?
Андрей Церкус говорит: 16.10.2008 в 13:47
2Сергей Волошин
Я чуть несогласен с вами. Начинающему программисту надо рассказать причину, почему так и в каких случаях это не выполняется.
Программист - это профессия, где надо знать причины, а не только следствие.

Ну и настоящий (пусть даже начинающий) программист это поймет и приобретет знание глубины вопроса. А ненастоящих учи не учи - толка не будет.
Сергей Волошин говорит: 16.10.2008 в 13:52
2Андрей Церкус: ну тут у нас же только конспект лекции, к которой нужно по хорошему сделать несколько семинаров - практических занятий, с примерами - как правильно и как неправильно и домашними заданиями с последующим анализом етс. Не знаю правда как это было на самом деле. Я тоже против объяснений типа “так надо”, “я так сказал” и т п.
COTOHA говорит: 16.10.2008 в 14:07
2 pako

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

я тоже надеюсь на самом деле это ж именно что конспект. бумажку эту можно причитать минут за 10-20, а лекция была полтора часа. и мнится мне, что я и примеры приводил валидные, и причины объяснял. вот. ну основное - я не надеялся всех и сразу переучить. было 2 цели:
- уверить тех, кто старается ошибок не делать, в том, что они на правильном пути;
- показать остальным, что то, что они делают - ошибки, а не норма. дальше те, кто проникся могут задавать вопросы, читать книги, гуглить и прочее.
COTOHA говорит: 16.10.2008 в 14:09
2 zwitter

кстати, автор статьи действительно считает, что Form1.Condition - глобальная переменная ?

а больше придраться не к чему? могу показать кусок кода, где она используется как глобальная переменная для передачи состояния межд�

Блог разработчиков