Студенты пишут быдлокод (им это сходит с рук)

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

double f = 15; // Сила броска.
Point a(10, 10); // Точка старта.
// Вычислить точку падения на поверхность высоты 1.5.
Point b = calculate(f, a, 1.5);

=>

double throwForce = 15;
Point throwStartPoint(10, 10);
double groundLevel = 1.5;
Point dropPos = calculateDropPosition(throwForce, throwStartPoint, groundLevel);

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

Но за отсутствие комментариев в низкоуровневых языках нужно отстреливать руки.

Здесь не спорю. В шелл-скриптах и makefile'ах тоже. И вообще везде, где невозможно свободно именовать сущности (действия, переменные).

что за ересь?
лучше уж табами

делов та добавь тест на кодестайл

Лор овцы, среди вас кто-нибудь преподавал будущим программистам? Допустимо ли ставить оценки за стиль и аккуратность кода? А вам самим в универе ставили?

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

Я не знаю ни одной публичной реализации..

В общем-то первый вариант (при наличии документации к методу calculate) тоже не надо, а вот документировать top-level функции (всякими *-doc) уже необходимо.

будущим программистам

Им - надо. Это же ведь не «информатика в экономике», где программирование даётся для общего знакомства.

С другой стороны, слишком зацикливаться на стиле и бить свинцовой трубой по пальцам не стоит. Куда важнее дать им системное мышление и понимание, что любой язык - это инструмент, который надо уметь выбирать, и что не бывает «программистов на C++», «программистов на Delphi» и «программистов на Java».

По моим ощущениям, к 3 курсу по-настоящему ценных ребят, которым ИНТЕРЕСНО писать программы уже очень хорошо видно. Главное не отпугнуть их.

документировать top-level функции (всякими *-doc)

Для проектной документации - да, согласен.

А собственно стиль кодирования допустимо наавязывать студентам?

Методом самывыпила. Принудительное насаждение стиля кодирование - это полнейший ппц и доказательство неадекватности преподавателя.

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

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

Функции на 5 экранов, переменные с названиями x, y, tmp1, tmp2,

Не вижу в этом ничего страшного - у Вас, небось, задачки-то алгоритмические.

ошибки не проверяются.

Ошибки ввода - это плохо, а ошибки в довольно очевидных алгоритмах - не очень страшно.

Некоторые даже отступы до сих пор для себя не открыли, так и фигачат

Они у Вас в нотепаде фигачат? Тогда чего уж там - дайте им какую-нибудь среду для набора текста. Хоть простейший Geany.

А вы им на первом занятии объясните возможные варианты хорошего оформления. 10-15 минут хватит что бы заинтересованные люди поняли.

Для руби есть RuboCop.

Минусуй еще за комментарии на русском.

Размечтался! Все просто поставят пиво "коллеге", и он сделает как надо (по его мнению). Сейчас в группе из 30 студентов обычно достойным учиться в ВУЗе является маскимум пара! А часто и вообще ни одного нет!!! Гнать этих дебилоидов поганой метлой, но кто будет преподавателям зарплату платить?

Они привыкнут к тому стилю, который навяжет им препод, а на работе будет другой стиль ;)

Простите, вы на каком ЯП программируете?

/**//**/

Мсье знает толк в извращениях О_о

Предлагаю делать так: не принимать задачи в которых совсем нет комментариев (если их слишком много, то тоже стоит задуматься, обычно предостаточно 1 комментария (если код не планируется использовать повторно, то иногда, даже это лишнее) (неплохо делать их не абы как, а, например, для doxygen, особенно если это библиотека) к каждой функции/методу класса) и переменные названы бессмысленно (это отсеет 50% студентов-быдлокодерв и им придется исправлять это), на и т.д. пока не переделают. А вот стиль формирования кода насаживать принудительно не надо (хотя за код в одну строчку стоит), это говорит о некомпетентности преподавателя, т.к. есть 100500 способов расстановки табов, пробелов и т.д., а ещё есть astyle, специально для поклонников отсутствия IDE, которая автоматом всё (ну или почти всё) выравнивает, и тем, кто не знает про него или аналогичные утилиты самим надо бить свинцовой трубой по голове. А код надо не только тестами прогонять, а ещё глазками (хотя бы бегло) просматривать (студенты ещё любят код друг у друга копировать с небольшими изменениями), за это вам и платят (хотя, если вы один ведете практику у 1000+ студентов, то будет тяжело).

А вообще если такие проблемы, то вы не там работаете (не умеете преподавать, сейчас мне жалко ваших студентов, учитесь пока не поздно, вспомните, как вам самим преподавали). Надо вести себя так, чтобы за быдлокод (даже если вы его принимаете, к примеру студент формально выполнил все ваши требования, но сделал что-то очень некрасивое о чём вы ему не говорили) было немного стыдно (только не унижайте студентов друг перед другом, фразы «мсье знает толк» обычно достаточно).

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

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

Вангую APL.

Если бы преподаватели еще не просто пузыри из ноздрей пускали.

Простите, вы на каком ЯП программируете?

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

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

Ну так 99% авторов статей и учебников по физике надо бы как следует выпороть шомполами, с оттяжечкой, с соленой водой, а потом заставить съесть томик МакКоннела без соли. Физики вообще та еще замшелая, ретроградная мразь. До них до сих пор не дошло, что кроме статеек с картинками и формУлками надо публиковать еще и весь использованный в обработке результатов софт и все грязные исходные данные. Так что ссылаться на этих утырков как на светоч истины просто глупо.

Эх, не видали Вы числодробилок на которых считает мировое сообщество... В лучшем случае там комментарии автора для себя. В худшем и того нету.

Как правило это одно файло на овер 4к строчек на каком нить фортране или в лучшем случае С. Иногда это хозяйство разнесено на неск файлов, и есть даже хидеры, но комментов там все равно хорошо если 1% от общего объема.

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

Простите, вы на каком ЯП программируете?

На многих. Лучше сразу спрашивай/пиши что хотел.

Я к тому клоню, что переменные в стиле x, y, z, a1, a2, a3, a4, b1, b2 ... не годятся во многих ЯП (есть исключения и задачи (напрмер, если мы что-то делаем на координатной сетке, то логично назвать координаты x и y), когда это не особо критично, но это именно исключения), как думаешь, почему от машинных кодов ушли к ассемблеру? Потому, что в ассемблере запись более понятна человеку. Переменные вида a1, a2, a3 и т.д. не понятны, т.к. на больших и длинных алгоритмах, который нельзя полностью хранить в голове постоянно приходится вспоминать, а что же я храню в переменной а12? Комменты на каждой строчке, где используется эта переменная просто увеличат твою работу в 2 раза, а объявление её может быть очень далеко и ты будешь долго искать (многие IDE тут тебе помогут, но это очень плохой стиль, постоянно надеяться на IDE) коммент к ней.

ЗЫ

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

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

ЧЯНТД?

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

Комментарий при объявлении переменной, а не при использовании.

многие IDE тут тебе помогут, но это очень плохой стиль, постоянно надеяться на IDE

Что плохого? При начальном изучении кодовой базы IDE практически необходима.

укрофашик чтоль?

Я вас умоляю. Этот язычок подталкивает к плохому стилю, чем все и пользуются. Типичный ынтерпрайз-продакшн-код на этом языке выглядит так:

Explicit recursion там, где можно было обойтись простой map — check

Process dictionary — любимое дело

genserver? не, я лучше продублирую его функциональность руками.

Функции на три экрана? Всегда пожалуйста.

Что такое функции высшего порядка? У меня есть буфер обмена.

В общем, низкий порог вхождения порождает чудовищ.

Допустимо ли ставить оценки за стиль и аккуратность кода? А вам самим в универе ставили?

Один препод сношал за отклонение от java conventions и «бессмысленное именование переменных». Иногда через чур. Но как говорится «тяжело в учении...» и препод хорошо теорию читал :)

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

В математике как то не смотрится имя переменной из нескольких символов, если это не индексы.

Математическая нотация - то еще говно. Один из самых мразячьих языков из созданных человечеством.

Есть шанс все исправить, и перейти на приличный язык, вроде того же Wolfram Mathematica.

нэ всэм, таварыщ.

Иногда через чур.

Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать. Убивать.

паскаль лучше?

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

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

Энтерпрайзный быдлокод это нежеление делиться учиться учить и созидать...

жесть... ты долго потом работу искал?

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

Переменные из нескольких символов успешно используются в около-CS текстах, и читаемость резко возрастает. Потому что neighbours и node in visited_nodes как-то понятнее, чем 𝕹 и 𝓥. Просто нынешние математически - тупая ретроградная секта, об этом ещё Арнольд говорил.

Да куда уж нам, убогим... Только сложное выражение обычно еще и длинное выражение. С длинными именами переменных это будет ОЧЕНЬ длинное выражение и очень плохо читаемое.

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

Когда функция занимает больше экрана, меня это уже несколько напрягает.

В любом случае, ни у меня ни у моих коллег короткие имена переменных никаких проблем не вызвывают. Если Вам кажется, что это таки проблема - возможно Вам нужно сменить профессию?;-)

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

http://legacy.python.org/dev/peps/pep-0008/#tabs-or-spaces

Spaces are the preferred indentation method.

Ты просто делаешь это неправильно.

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

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

Когда функция занимает больше экрана, меня это уже несколько напрягает.

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

ошибки не проверяются

Never test for an error condition if you don't know how to handle

Забей. Лучше учи студентов (хотя бы) подходу программы = алгоритмы + структуры данных.

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

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

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

Вопрос только в том, хочешь ли ты тратить на это время?

Безусловно! Но во первых это не всегжа можно сделать эффективно, во вторых для этого нужны какие то основания, акромя мнения анонимуса с ЛОР-а по поводу необходимости испольщования длинных имен переменных.

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