CppCheck можно подключить к студии как внешний инструмент. Там есть флажок --template=vs как раз для форматирования вывода под студию. Работает с любой версией начиная с шестой.
Однако, иногда имена параметров излишни, поэтому в Objective-D их можно опустить.
Это не работает. Именованные параметры есть и в питоне, и в шарпе, и вообще много где. Но если их можно опускать, их будут опускать.
В Objective-C это в общем-то не именованные параметры (функции там сишные, в Си такой фичи нет), а часть синтаксиса сообщений. Обязательная, естественно. Имена невозможно опустить, поэтому приходится их продумывать. В итоге средний код на Objective-C читается прекрасно с минимальной подготовкой читающего. Огромное влияние на популярность языка оказывает то, что я могу за секунды нагуглить пример, понять его и переделать под свои нужды. Двадцать первый век же, никто не читает документацию. А так код сам себя документирует достаточно успешно.
Для С++, кстати, есть Cocos-2dx. Но он откровенно отстает от оригинала.
Идея-то интересная. Но типографике как дисциплине уже много сотен лет, все нюансы со знаками, кернингом, полями, интервалами отработаны очень большой практикой. А нюансы эти как раз и нужны для того, чтобы сделать текст легче читаемым. Вряд ли можно просто заменить буквы квадратами и оставить при этом все преимущества обычной книжной верстки.
По-моему, тут нужны принициально новые знаки препинания, правила переносов, пробелов и междустрочных интервалов.
Было бы еще интересно увидеть цифры какого-нибудь исследования. Мол, у такой-то группы читалось столько-то слов в минуту, после какого-то времени тренирововок стало читаться столько-то.
в реальной жизни, не всегда получается выдавать красивый и логичный код
то и
быть внимательным, и не забывать исправлять комментарии при исправлении кода
тоже не получится.
С одной стороны, комментарии — зло, хотя и зло разной степени необходимости. Я сейчас сталкиваюсь с проблемой, что даже в экстремуме: устаревший ассемблерный код, тонны его, — комментарии помогают и путают примерно одинаково. Нет абсолютно никакой гарантии, что в коде слева от комментария происходит именно то, что в нем написано. Все критичное приходится проверять и перепроверять в коде. Комментарии сильно помогают в том, чтобы понять общую суть, помогают ориентироваться в тексте программы, помогают быстро пролистать много страниц по диагонали. Но в деталях на них полагаться нельзя, а детали как раз и важны в первую очередь.
Проблема в том, что есть множество инструментов для валидации и верификации кода. Есть статические и динамические анализаторы, есть профайлеры и отладчики, есть модульное, интеграционное, регрессионное тестирование. А вот комментарии верифицировать можно только вручную и только через ревью.
Можно, конечно, формализировать ревью. Взять, к примеру, методику Фагана, она правда тоже для кода, а не комментариев. Но она требует участия минимум трех участников на протяжении часа-полутора и позволяет инспектировать 200-300 строк за сессию. Это очень долго, дорого и никогда не применяется для комментариев. Вообще никогда. А вот документация, например, там где надо, в рамках формальной процедуры верифицируется.
И конечно же прозрачный идеоматичный код с говорящими именами и легкочитаемыми конструкциями лучше, чем грязный код с комментариями. И все-таки двадцать первый век на дворе, на современных языках можно писать много выразительнее, чем на алголе и ассемблере. И да, внезапный комментарий действительно говорит о том, что с кодом что-то не так.
Но с другой стороны, с кодом всегда что-то не так. Такая уж природа ПО. Считается, что хороший софт имеет плотность дефектов менее одного на тысячу строк кода. То есть даже при самых жестких V&V процедурах, никто и не ожидает, что программа будет безошибочной. Всего лишь дефектной в рамках дозволенного. Даже если процедура утверждает, что дефектов нет, это означает только то, что они не были найдены в рамках конкретной процедуры. Нулевая плотность дефектов — это не гарантия, а обещание.
Поэтому если кто-то думает, что может делать свой код лучше принципиально не пользуясь комментариями, это самообман. Код костыли содержит всегда, и лучше их явно обозначать комментариями, чем умалчивать.
Но и если кто-то думает, что может сделать свой код лучше комментируя все подряд без очевидной необходимости, это тоже самообман. Поддержка комментариев стократно сложнее поддержки кода, а внимания ей уделяется несравнимо меньше.
Не надо трогать Герона. Можно взять сумму векторов векторных произведений от точки к вершинам (главное не потерять порядок) и сравнить квадрат ее нормы с квадратом нормы векторного произведения двух любых сторон. Это те же площади, но без корней и конских формул, а если компилятор позволяет, еще и с мультискалярными операциями на всех векторных вычислениях.
К слову сказать, Айверсон придумал APL (IBM) именно как разновидность математической нотации. Новая нотация должна быть проще, логичнее и удобно записываться в строчку. Ну и в целом у него получилось. К классической нотации даже до учебника по высшей математике привыкают лет десять, APL можно освоить за семестр или два.
J страдает не из-за плохой нотации, а из-за неподходящих средств ее выражения. Нотация хорошая. Но для того, чтобы читать J, надо не просто знать нотацию, а еще и то, как он ложится на ASCII. Это двойной барьер для восприятия, да. Хотя и преодолимый.
Проблема читаемости J в том, что это адаптация APL под ASCII. Нотация APL непривычная, но неплохая. Не хуже привычной математической. Конечно, если взять его графемы и «втиснуть» в алфавит телетайпа, получится плохо. Это примерно как писать по-русски латиницей, только в восемнадцать раз хуже.
И вот меня все не покидает одна забавная конфабуляция: APL на планшетах. Символы можно рисовать пальцем, например, можно выбирать на нарисованной клавиатуре. Хранить код в уникоде вообще не проблема. Краткость в условиях небольшого экрана — огромный плюс. Мне почему-то кажется, что для обработки каких-нибудь данных в полевых условиях это все было бы полезно и интересно.
Нетрудно заметить, что как мы думаем, так и записываем код
Обратное верно. Программированию стоит учиться, чтобы научиться думать больше и лучше.
Например, лисп, пролог, смолтолк и D несут в себе заряды идей, которые меняют во многом сам образ мышления. Пролог ломает голову декларативностью, лисп — макросами, смолтолк — объектами и интерфейсами, D — статическим метапрограммированием. Поломанная голова срастается и становится крепче, чем была когда-либо до этого. Суть такого обучения понятна и очевидна.
Фортран же, равно как и питон и даже С++ — языки практические и потому неинтересные. Они во многом впитывают чужие идеи, подстраивая их под свой синтаксис и свою инфраструктуру. Плюсы, например, имеют и объекты, и метапрограммирование, и функции как объекты первого рода, но все это намного больше похоже на эмуляцию, чем реализацию. Как говорил Алан Кей: «Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду C++».
Поэтому может Фортран и годится в качестве первого языка, но разве что первого. С дидактической точки зрения он не так уж ценен.
Офисное пространство на этом фоне может показаться просто рабочим раем — особенно часто такое мнение встречается среди тех, кто пробовал какое-то время работать удалённо, но не сумел правильно всё организовать и вернулся в офис.
Потому что офисное пространство и предназначается для работы. Сделать его раем — работа работодателя.
И да, личное общение очень важно. Нам, интровертам, приятно думать, что это не так, но это так. Одно совещание вживую способно решить проблему, которую можно в тимспике обсасывать месяц, а электропочтой футболить от полугода до вечности. Простой разговор с разработчиком проясняет проблему в разы лучше, чем любой чат или голос. Просто потому что когда я пришел ногами, я вроде как гость и живой человек, с которым можно пообщаться. А если я — телефонный звонок, то я отвлекающий фактор, который надо устранить.
Меня все время, что я работал удаленно, не покидало чувство, что я в танке заряжающий. Вроде как что-то происходит, кто-то побеждает, а я только снаряды забрасываю и гадаю на копоти: нас, или мы? Чтобы притупить это чувство пришлось съездить в Киев, поймать там лида, чтобы он мне за полчаса нарисовал на бумажках, что вообще происходит. Этот разговор оказался полезнее, чем вся проектная документация.
Я так думаю, если книга хорошая, то она увлекательная, аддиктивная. Если аддиктивная, то это наркотик. А если наркотик, то и распространять его надо через криминальную сеть пушеров. Тогда да, цены по 500 евро за том никого особо не удивят. И да, аресты, облавы, книжная мафия, изъято три тонны подпольной литературы, — вся эта романтика обязана присутствовать. Иначе за что платить-то?
А если книга плохая, то ее издавать и вовсе не стоит.
Как всегда хочется несферических примеров. Я своим студентам контрольные генерировал скриптом. Это действительно удобно и здорово. Но увы, получалось все-таки не так сказачно, как в примере с Аней-Светой-Мариной, потому что воросы касались вещей весьма конкретных, например, делегатов C#, и пространства для рандомизации вопросов фактически не получалось.
Даже просто перемешать вопросы по билетам, чтобы билеты не повторялись — уже не вполне автоматизируемая задача. Некоторые вопросы просто не должны стоять рядом, потому что один является ответом на второй. Я обычно билеты генерировал с запасом, а потом фильтровал выдачу вручную, как Лукашенко в анекдоте. Вот поэтому было бы здорово посмотреть, как ваш метод работает на практике.
И еще отдельный вопрос. Там где, например, решить уравнение. Задание я построю, ок. А решение? Ну ладно линейное уравнение, а если что-то поинтересней?
Да, это я в курсе. Но J по большому счету и нужен для того, чтобы можно было в ASCII. А вот APL потрогать (буквально!) было бы по меньшей мере забавно.
Кажется, я где-то слышал про попытки возродить APL на планшетах. Нет клавиатуры — нет проблемы с символами, стилом или пальцем можно нарисовать что угодно.
Первая мысль — написать свой интерпретатор своего скриптового языка, выкидывается из мозга через несколько секунд. Логика игрока определенно не стоит таких жутких затрат.
Тут есть подвох. Ядро языка писать несложно, никаких больших затрат там не случается. А вот «вывести концы» собсвтенно объектной модели так, чтобы ей мог с удовольствием пользоваться скриптер, — вот это задача намного более сложная и интеллектоемкая. И она не решается простой прикруткой Луа, Питона или чего угодно еще.
Первый мой опыт в этой области касался AngelScript. Ну, это было давно, Луа еще был не на слуху, а вот этот ангельский скриптец казался нам тогда вполне годным. К тому же у него был сиподобный синтаксис, что с нашей программистской точки зрения было несомненным плюсом. Мы прикрутили скриптовый движок и тупо вывели интерфейсы один в один, но не все. Получилось, что у нас есть язык, на котором предполагается писать логику игры, который хуже чем плюсы, имеет меньше возможностей, чем плюсы, но при этом похож на плюсы и чтобы пользоваться им, надо знать плюсы. Скриптеры посмотрели на это дело, сказали: «как-нибудь в другой раз». В итоге сцены на всем этом мы же и писали, потому что больше некому.
Следующий опыт касался как раз Луа. Прикрутили Луа, дали скриптерам, они засели и быстро-быстро настрочили тонну говнокода. Им положено, они не программисты, они геймдизайнеры, им по штату положено делать сцены, а не код рефакторить. Естественно, вскоре застряли во всем этом и опять же разгребать все пришлось нам, программистам.
А вот в третий раз от меня ненадолго отвернулось начальство, и, пока никто не видит, я внезапно написал собственный язык с блекджеком и шлюхами. Точнее, писал его не я, я только программировал. Сам язык создавал по-сути Женя Гомельский, геймдизайнер, который просто знал, чего хочет и умел это сформулировать. Язык получился местами очень даже ничего. Там были предлоги, похожие на именнованные параметры в Обджектив-Си, местоимение «it», как в Хаскелевском ghci, метапрограммирование в стиле миксинов Ди, и даже некоторые уникальные вещи, как, например, переменная по умолчанию. Ну, можно было, например, написать цикл так: [for {i=0} {i++; i<10}], а можно так: [10x]. Во втором случае счетчиком цикла считалась переменная по умолчанию "?".
Мы выпустили с ним пару проектов, вполне между прочим успешных, а потом перешли на новую платформу и забросили скрипты вообще в пользу машины состояний и визуального программирования. И, честно сказать, это было определенное облегчение. Писать языки надо уметь, я не умею. Кроме красивых фичей, он закономерно оброс костылями и велосипедами. Если код на языке был вполне даже читаем, то код самого интерпретатора заболотило по самые осины. Его стало очень сложно поддерживать. Причем, не само ядро, конечно, там-то как раз ничего сложного изначально не было, а вот все эти «концы». Например, в одном проекте меню выезжает справа, в другом — снизу, и в язык попадают, условно говоря, две взаимоисключающие функции для красивого выезда меню. И вот так вот все.
То есть, какой вывод я хочу сделать. Программировать сложно. Без опыта и усердия любой выбор скриптового решения приведет к говну и костылям.
Деление флота на ноль вполне соотвествует IEEE 754. Именно поэтому в HICPP рекомендуется в таком случае вводить какие-нибудь предусловия. Пусть лучше грациозно падает прямо сейчас, чем когда-нибудь еще.
Это не работает. Именованные параметры есть и в питоне, и в шарпе, и вообще много где. Но если их можно опускать, их будут опускать.
В Objective-C это в общем-то не именованные параметры (функции там сишные, в Си такой фичи нет), а часть синтаксиса сообщений. Обязательная, естественно. Имена невозможно опустить, поэтому приходится их продумывать. В итоге средний код на Objective-C читается прекрасно с минимальной подготовкой читающего. Огромное влияние на популярность языка оказывает то, что я могу за секунды нагуглить пример, понять его и переделать под свои нужды. Двадцать первый век же, никто не читает документацию. А так код сам себя документирует достаточно успешно.
Для С++, кстати, есть Cocos-2dx. Но он откровенно отстает от оригинала.
По-моему, тут нужны принициально новые знаки препинания, правила переносов, пробелов и междустрочных интервалов.
Было бы еще интересно увидеть цифры какого-нибудь исследования. Мол, у такой-то группы читалось столько-то слов в минуту, после какого-то времени тренирововок стало читаться столько-то.
то и
тоже не получится.
С одной стороны, комментарии — зло, хотя и зло разной степени необходимости. Я сейчас сталкиваюсь с проблемой, что даже в экстремуме: устаревший ассемблерный код, тонны его, — комментарии помогают и путают примерно одинаково. Нет абсолютно никакой гарантии, что в коде слева от комментария происходит именно то, что в нем написано. Все критичное приходится проверять и перепроверять в коде. Комментарии сильно помогают в том, чтобы понять общую суть, помогают ориентироваться в тексте программы, помогают быстро пролистать много страниц по диагонали. Но в деталях на них полагаться нельзя, а детали как раз и важны в первую очередь.
Проблема в том, что есть множество инструментов для валидации и верификации кода. Есть статические и динамические анализаторы, есть профайлеры и отладчики, есть модульное, интеграционное, регрессионное тестирование. А вот комментарии верифицировать можно только вручную и только через ревью.
Можно, конечно, формализировать ревью. Взять, к примеру, методику Фагана, она правда тоже для кода, а не комментариев. Но она требует участия минимум трех участников на протяжении часа-полутора и позволяет инспектировать 200-300 строк за сессию. Это очень долго, дорого и никогда не применяется для комментариев. Вообще никогда. А вот документация, например, там где надо, в рамках формальной процедуры верифицируется.
И конечно же прозрачный идеоматичный код с говорящими именами и легкочитаемыми конструкциями лучше, чем грязный код с комментариями. И все-таки двадцать первый век на дворе, на современных языках можно писать много выразительнее, чем на алголе и ассемблере. И да, внезапный комментарий действительно говорит о том, что с кодом что-то не так.
Но с другой стороны, с кодом всегда что-то не так. Такая уж природа ПО. Считается, что хороший софт имеет плотность дефектов менее одного на тысячу строк кода. То есть даже при самых жестких V&V процедурах, никто и не ожидает, что программа будет безошибочной. Всего лишь дефектной в рамках дозволенного. Даже если процедура утверждает, что дефектов нет, это означает только то, что они не были найдены в рамках конкретной процедуры. Нулевая плотность дефектов — это не гарантия, а обещание.
Поэтому если кто-то думает, что может делать свой код лучше принципиально не пользуясь комментариями, это самообман. Код костыли содержит всегда, и лучше их явно обозначать комментариями, чем умалчивать.
Но и если кто-то думает, что может сделать свой код лучше комментируя все подряд без очевидной необходимости, это тоже самообман. Поддержка комментариев стократно сложнее поддержки кода, а внимания ей уделяется несравнимо меньше.
J страдает не из-за плохой нотации, а из-за неподходящих средств ее выражения. Нотация хорошая. Но для того, чтобы читать J, надо не просто знать нотацию, а еще и то, как он ложится на ASCII. Это двойной барьер для восприятия, да. Хотя и преодолимый.
И вот меня все не покидает одна забавная конфабуляция: APL на планшетах. Символы можно рисовать пальцем, например, можно выбирать на нарисованной клавиатуре. Хранить код в уникоде вообще не проблема. Краткость в условиях небольшого экрана — огромный плюс. Мне почему-то кажется, что для обработки каких-нибудь данных в полевых условиях это все было бы полезно и интересно.
Но почему-то J под андройд есть, а APL нет.
Обратное верно. Программированию стоит учиться, чтобы научиться думать больше и лучше.
Например, лисп, пролог, смолтолк и D несут в себе заряды идей, которые меняют во многом сам образ мышления. Пролог ломает голову декларативностью, лисп — макросами, смолтолк — объектами и интерфейсами, D — статическим метапрограммированием. Поломанная голова срастается и становится крепче, чем была когда-либо до этого. Суть такого обучения понятна и очевидна.
Фортран же, равно как и питон и даже С++ — языки практические и потому неинтересные. Они во многом впитывают чужие идеи, подстраивая их под свой синтаксис и свою инфраструктуру. Плюсы, например, имеют и объекты, и метапрограммирование, и функции как объекты первого рода, но все это намного больше похоже на эмуляцию, чем реализацию. Как говорил Алан Кей: «Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду C++».
Поэтому может Фортран и годится в качестве первого языка, но разве что первого. С дидактической точки зрения он не так уж ценен.
Потому что офисное пространство и предназначается для работы. Сделать его раем — работа работодателя.
И да, личное общение очень важно. Нам, интровертам, приятно думать, что это не так, но это так. Одно совещание вживую способно решить проблему, которую можно в тимспике обсасывать месяц, а электропочтой футболить от полугода до вечности. Простой разговор с разработчиком проясняет проблему в разы лучше, чем любой чат или голос. Просто потому что когда я пришел ногами, я вроде как гость и живой человек, с которым можно пообщаться. А если я — телефонный звонок, то я отвлекающий фактор, который надо устранить.
Меня все время, что я работал удаленно, не покидало чувство, что я в танке заряжающий. Вроде как что-то происходит, кто-то побеждает, а я только снаряды забрасываю и гадаю на копоти: нас, или мы? Чтобы притупить это чувство пришлось съездить в Киев, поймать там лида, чтобы он мне за полчаса нарисовал на бумажках, что вообще происходит. Этот разговор оказался полезнее, чем вся проектная документация.
Книжечка, кстати, страниц тридцать со всеми формальностями.
А если книга плохая, то ее издавать и вовсе не стоит.
Даже просто перемешать вопросы по билетам, чтобы билеты не повторялись — уже не вполне автоматизируемая задача. Некоторые вопросы просто не должны стоять рядом, потому что один является ответом на второй. Я обычно билеты генерировал с запасом, а потом фильтровал выдачу вручную, как Лукашенко в анекдоте. Вот поэтому было бы здорово посмотреть, как ваш метод работает на практике.
И еще отдельный вопрос. Там где, например, решить уравнение. Задание я построю, ок. А решение? Ну ладно линейное уравнение, а если что-то поинтересней?
Одно но, я не уверен, что это мне не приснилось.
Тут есть подвох. Ядро языка писать несложно, никаких больших затрат там не случается. А вот «вывести концы» собсвтенно объектной модели так, чтобы ей мог с удовольствием пользоваться скриптер, — вот это задача намного более сложная и интеллектоемкая. И она не решается простой прикруткой Луа, Питона или чего угодно еще.
Первый мой опыт в этой области касался AngelScript. Ну, это было давно, Луа еще был не на слуху, а вот этот ангельский скриптец казался нам тогда вполне годным. К тому же у него был сиподобный синтаксис, что с нашей программистской точки зрения было несомненным плюсом. Мы прикрутили скриптовый движок и тупо вывели интерфейсы один в один, но не все. Получилось, что у нас есть язык, на котором предполагается писать логику игры, который хуже чем плюсы, имеет меньше возможностей, чем плюсы, но при этом похож на плюсы и чтобы пользоваться им, надо знать плюсы. Скриптеры посмотрели на это дело, сказали: «как-нибудь в другой раз». В итоге сцены на всем этом мы же и писали, потому что больше некому.
Следующий опыт касался как раз Луа. Прикрутили Луа, дали скриптерам, они засели и быстро-быстро настрочили тонну говнокода. Им положено, они не программисты, они геймдизайнеры, им по штату положено делать сцены, а не код рефакторить. Естественно, вскоре застряли во всем этом и опять же разгребать все пришлось нам, программистам.
А вот в третий раз от меня ненадолго отвернулось начальство, и, пока никто не видит, я внезапно написал собственный язык с блекджеком и шлюхами. Точнее, писал его не я, я только программировал. Сам язык создавал по-сути Женя Гомельский, геймдизайнер, который просто знал, чего хочет и умел это сформулировать. Язык получился местами очень даже ничего. Там были предлоги, похожие на именнованные параметры в Обджектив-Си, местоимение «it», как в Хаскелевском ghci, метапрограммирование в стиле миксинов Ди, и даже некоторые уникальные вещи, как, например, переменная по умолчанию. Ну, можно было, например, написать цикл так: [for {i=0} {i++; i<10}], а можно так: [10x]. Во втором случае счетчиком цикла считалась переменная по умолчанию "?".
Мы выпустили с ним пару проектов, вполне между прочим успешных, а потом перешли на новую платформу и забросили скрипты вообще в пользу машины состояний и визуального программирования. И, честно сказать, это было определенное облегчение. Писать языки надо уметь, я не умею. Кроме красивых фичей, он закономерно оброс костылями и велосипедами. Если код на языке был вполне даже читаем, то код самого интерпретатора заболотило по самые осины. Его стало очень сложно поддерживать. Причем, не само ядро, конечно, там-то как раз ничего сложного изначально не было, а вот все эти «концы». Например, в одном проекте меню выезжает справа, в другом — снизу, и в язык попадают, условно говоря, две взаимоисключающие функции для красивого выезда меню. И вот так вот все.
То есть, какой вывод я хочу сделать. Программировать сложно. Без опыта и усердия любой выбор скриптового решения приведет к говну и костылям.
А туториал годный, кстати.