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

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

Кажись, у Макконнелла. Пишем комменты того, что будем делать. Под комментами пишем код. Комменты удаляем, ибо они повторяют код :)

Это спорно. Тут 95℅ не знают английского, поэтому сказать синонимы к слову смогут от силы 1-2 из 10-15. В его примерах это чётко прослеживается: 1 из 15 синонимов окажется коротким словом и точно опишет сущность переменной.

Какие есть разумные статические чекеры для C, C++, C#, Java и Pascal (сейчас разрешается любой из этих языков по выбору)?

А если студент хочет другой язык, скажем Python или Tcl?

Это спорно

Что именно спорно?

Тут 95℅ не знают английского,

Как человек, знающий русский, могу сказать - фразы в духе «тут 95% - быдло малограмотное» звучат как тупые порты. Если ты не понтоваться хотел, говори «95% из нас».

поэтому сказать синонимы к слову смогут от силы 1-2 из 10-15

Это программа, оперирующая терминами, а не художественная литература, оперирующая метафорами.

1 из 15 синонимов окажется коротким словом и точно опишет сущность переменной.

Писать везде короткое слово velocity вместо v. Прекрасная идея.

Что именно спорно?

Спорно то, что поиск синонима это аналог венгерской нотации.

Писать везде короткое слово velocity вместо v.

И опыта у нас мало. Тебе дали кусок кода и эта v может быть verbose, version, vector, да чем угодно. Круто? Лень порождает ещё большую лень и кусок кода превращается в ещё больший кусок г. Чтобы этого не было Макконнелл и учит писать осмысленный код.

Спорно то, что поиск синонима это аналог венгерской нотации.

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

Тебе дали кусок кода и эта v может быть verbose, version, vector, да чем угодно. Круто?

В качестве страшилки аутсорсера - да, нормально. В реальности всё немного не так. И кстати, комментарии нужны.

Макконнелл и учит писать осмысленный код.

Если бы его книга состояла из фразы «пишите осмысленный код», она была бы полезнее.

Если не разбираешься в предметной области, то хоть v, хоть velocity, хоть light_velocity_in_first_matter одинаково непонятно и ничем не поможет. Если разбираешься, то v вполне достаточно.

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

Есть терминология, принятая в предметной области.

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

Хорошо опираться на простые задачи, вроде расчёта ускорения, силы или из химии, расчёт молевого числа. Просто привычки, что у всех все как у меня, означает только решения как у Поттеринга, я д'Артантян, а кругом [пип].

Забей на это. Когда кому-нибудь из них понадобится написать что-нибудь больше 1000 строк кода. То он сам поймет насколько аккуратность важна. Ну или не поймет и будет страдать, но в таком случае с ним что-то не так.

Кстати, почему это не в толксах а в девелопменте?

Пусть делают ревью кода друг друга и ставят оценки.

А если в коде решаются несколько задач, из разных областей и идёт пересечение принятых обозначений?

Это как-то оправдывает придумывание своей терминологии на основе коротких синонимов?

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

Ну вот у меня на руках два драйвера сетевых карт. Один - фирменный, Ъ-ынтерпрайзный, с длинными угребищными^Wмнемоническими идентификаторами, другой - идиоматичный линуксовый. Второй работает лучше :) А свои идиомы вырабатываются везде. Идентификатор ndev ничем не хуже network_device, но короче.

на си вечное глючное текущее говно

Если учесть что сейчас почти все ядра ОС, низкоуровневый юзерспейс, интерпретаторы и ВМ написаны на С, вам с компьютером должно быть не очень комфортно

Всячески сочувствую

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

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

среди вас кто-нибудь преподавал будущим программистам?

конечно :D

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

Не только допустимо, но и необходимо. Код во-первых должен быть рабочим, во-вторых не валится на нестандартные, но возможные данные, а в третьих _понятным_, если нет стиля и аккуратности, нет и понятности, а значит и оценка за задание ниже. Самое главное, чтоб это было согласованно с лектором и объяснено студням _сразу_ с первого занятия почему так.

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

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

Как вообще оценивать общую адекватность кода

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

Насколько я помню, на курсере курс по Scala проверял не только корректность, но и стиль написания кода автоматически. Так что ищите автоматические чекеры стиля, может есть даже generic какие-то для разных язычков.

какое тз такое и решение. Если ты говоришь студенту написать функцию которая принимает два числа складывает их и выводит на экран то он напишет 5 строк и будет прав, если он пишет функцию на 5 экранов и это не вызывает у него потом трудностей то он прав, проблема больших функций в сложности понимания отладки и удобства чтения, раз у него нет таких проблем то он прав, твоя задача сделать такое тз что бы он напоролся на свои привычки давать имена переменным типа х у, делать функции в 5 экранов и тд. если он хоть сколько-то программист то поймёт что он делает не так, если не поймёт то можно ему сказать что он так долго отлаживает прогу из за сложной функции в 400 строк. Да и функции в 400 строк быть могут но только если они такие одни на 100 функций размером в 20 строк, и как пишет макконел что если мы пишем функцию и она получается огромной и мы просто разбиваем её на маленькие это не решает проблему плохого проектирования, в таком случае нужно смотреть на её название и на роль в интерфейсе, возможно её большой размер в данном случае не является признаком плохого интерфейса

плохого проектирования*

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

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

почему одновременно point и position? какая между ними разница?

зачем through перед force? Есть еще одна сила в том же вызове?

зачем through и start перед point? В контексте есть еще одно точка?

start и drop --- не соотвествую друг другу, (start-end, drop-??)

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

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

А вообще, помню, нас тра..ли так: Пишешь ты лабу, потом подходит преподаватель, смотрит твой код, спрашивает тебя по нему. Не ответишь - препод пошел к другому, а ты жди; ответишь - препод начинает запускать твою прогу и тыкать все клавиши подряд, или сделает вызов функции с каким-нибудь неожиданным аргументом. Если все ок - то это только 20% зачета по этой задаче. Далее студент писал отчет, который возвращался по 20 раз с исправлениями типа: переменная a должна нести какое-нибудь логическое название,или, в блок-схеме: счетчик i < 0 нужно поменять на что то другое (Пока вводятся только числа) ну и т.д. Это Заставляло писать отчет высоким техническим языком. НУ и последний этап - защита по теории: вопросы прямо по твоему коду... И так было с каждой лабой, я уже молчу про курсовые и экзамен...

И да, ко всему этому, требовалось соблюдать ГОСТ при написании отчета.

Стиль и аккуратность оценивать нужно. Стайл-чекер прикручивать нельзя. Ручками, ручками. Преподавать — тоже работа.

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

Когда учился на первом курсе, с нас требовали, чтобы переменные и комментарии в программе были названы по-русски. Мотивировалось это тем, что раз мы учимся в русском вузе, вот и следует излагать свои программистские мысли на великом и могучем. В общем-то, здравый подход, но вот только инструментарий (тогда ещё учились на Borland Pascal'е) ему не способствовал: Юникода-то нет! Поэтому всё сводилось к транслиту и появлялись переменные вроде matritsa, summa и rezultat.

Нынче в моей альма-матер уже на первом курсе дают default programming language, так что сегодняшним студентам живётся легче. Не помню, обращали ли внимание на отступы и форматирование, если и обращали, то не сильно. Хотя по-хорошему, надо за каждую табуляцию в исходниках балл отнимать, чтобы эта дурь про «indent with tabs align with spaces» из головы вылетела.

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

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

вот дурь! Достаточно было запустить/продемонстрировать комплект юнит-тестов.

их еще надо написать...

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

Не согласен. Чем меньше функция, тем примитивнее должны быть действия , имена - вплоть до i, n, a, b .... Ибо избыточно.

Коментарии в теле: кандидаты на отдельный блок вне тела. Вместо того чтобы писать fooI barI например, лучше ...foo|bar... {...I...} и т.д.

Имя функции должно быть не более значимо, чем её миссия. Удачное имя: main

Следует почитать соглашения по стилю программирования у Линуса где-то в исходниках ядра есть такой файл - достаточно. Кстати там не без характерного юмора.

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

а генерить? а по аннотациям? а рефлексия?

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

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

Плюсую, кстати

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

Вряд ли в рамках дисциплины «Язык программирования АБВГД» такое прокатит, а вот в рамках «Технологии программирования» - думаю будет ок.

по стилю программирования у Линуса

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

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

Сам хотя бы понял что написал?

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

авторитетов нет!

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

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

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

Поддерживаю.

Если совсем не ясно - ремеслу в (хороших) ВУЗах не учат.

Да там вообще ничему не учат. Научишься сам - повезло, не научишься - зря 4-5-6 лет протирал штаны за партой. Теперь вопрос: а нахрена нужен ВУЗ? Кто хочет учиться сможет это и без него делать, кто не хочет - и так не будет.

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

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

А вам самим в универе ставили?

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

Навязывай что-нибудь понейтральнее. Стайлчекер не нужен.

Идентификатор ndev ничем не хуже network_device

Но гораздо лучше $n. А $version или на крайняк $ver куда лучше $v. Ибо если $ndev и $ver еще могут бызвать хоть какие-то ассоциации, то $n и $v уж точно не вызовут, при беглом взгляде на код. Еще неплохо переменные именовать по типу сущности которая там лежил. Типа

class Bus { ... }
...
foreach($aBuses as $oBus) { ... }

Еще неплохо переменные именовать по типу сущности которая там лежил.

А то.

BOOL GetTextExtentExPoint(
  _In_   HDC hdc,
  _In_   LPCTSTR lpszStr,
  _In_   int cchString,
  _In_   int nMaxExtent,
  _Out_  LPINT lpnFit,
  _Out_  LPINT alpDx,
  _Out_  LPSIZE lpSize
);

Красота же.

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

int cchString

WTF???

_In_ int nMaxExtent,
_Out_ LPINT lpnFit,
_Out_ LPSIZE lpSize

А это хорошо, да.

Я вот только не пойму нафига в вендовом апи придумали 100500 своих типов, которые 1-в-1 повторяют стандартные.

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

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

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

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

Если у тебя полная власть над предметом (лекции, практики и лабы), можно проводить практики по паттернам, и потом добровольно-принудительно требовать их использование в лабах (например, решить задачу X с использованием паттерна Y)/

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

А если студент придерживается GNU стиля, а не K&R, например?

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