Со своей колокольни.

Всячески одобряю это начинание.

А зачем оно тогда нужно? почему бы тогда не называть функции каким-нибудь случайно сгенерированным словом чтобы не тратить время на придумываение?

К чему утрировать ?

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

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

они протолкнули свой убогий английский язык в качестве универсального

Как и где?

Из своего опыта (по этому вопросу) могу сказать что в ООН закреплены несколько языков, которые имеют статус «’языков межнационального общения’».

уродский префикс ary_ из-за отсутствия классов

class MutableArray {
    /** 
    * Change capacity of the current Array and resize it if needed
    *
    * Этого описания не нужно, потому что имя функции почти слово в слово передает содержимое шапки
    *
    * @param newCapacity: Long - этого описания не нужно,
    *                            потому что всё уже понятно из контекста
    *                          функция "изменить длину" с одним параметром с именем "длина"
    *                          сложно не догадаться
    * @return - этого описания не нужно, 
    *           т.к. type inference само подставит нужный тип,
    *           (его даже в коде не прописано явно!),
    *           который в данном случае будет Unit, 
    *           что подскажет пользователю о том, 
    *           что это функция с сайд-эффектами, 
    *           изменяющая текущий класс
    */
    def changeCapacityAndResize(newCapacity: Long) = { ... }
}

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

уродский префикс ary_

Никогда бы не догадался, что ary — array. Я уж про кружки Эйри даже подумал...

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

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

Надо писать код так, что если шапка перестанет быть правильной, смысл кода всё равно можно было бы понять.

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

писать комментарии на русском — фу

быть тобой, вот это настоящее фу. а комментарии на русском --- это стильно, можно, молодежно.

Веселый ты.

ЧСВ

уродский префикс ary_ из-за отсутствия классов

Да какая разница какой там префикс, если одними названиями методов один фиг не уедешь

К примеру

VALUE
rb_ary_join(VALUE ary, VALUE sep)

/// и следом

static VALUE
rb_ary_join_m(int argc, VALUE *argv, VALUE ary)

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

Люди годами пилят софт и пишут по-английски и комментарии, и описания коммитов, и даже документацию
При этом люди плохо разбираются в английском

Годами пишут на английском и до сих пор не могут его освоить? В морг.

Кстати, вот точно: зачем Eclipse ставит в качестве кодировки - системную? Это же диверсия какая-то!

Человека, который сохраняет самообладание при виде интерфейса Эклипса, такие мелочи не волнуют.

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

У вас ватник расстегнулся.

Шел 2014 год

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

свой убогий английский язык

Проиграл.

Ыыыыыы

static int
sort_1(const void *ap, const void *bp, void *dummy)

/// O_o и ноль комментариев.

static int
sort_2(const void *ap, const void *bp, void *dummy)

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

Поэтому половина описаний коммитов состоит вот из этого мусора: «fix», «add fix», «change method», «use new variable» и прочих творений Кэпа

Пиши поэму из этого «мусора». Включи фантазию и пару слов.
Тогда и японец, и испанец, и бурят поймут на ломанном английском, что ты «fix» memory leak issue with «change method» blah_blah_blah(void)

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

наличие шапки снимает необходимость нормально называть параметры? ))) Т.е. после высокоинформативной шапки можно без зазрения совести нафигачить так: int x(y,z,z2) ? )))

+

case class CommandLineArguments(arguments: List[String]) {...}

class RubyArray {def joinMElements(commandLineArguments: CommandLineArguments) = {...}}

class RubyArray {def join(commandLineArguments: CommandLineArguments) = {...}} //декоратор для join_0, join_1, join_m

class CodeParser {implicit commandLineArguments => ... }

и соответствующее использование будет:

class CodeParser { ... val arr = RubyArray(1,2,3).join ... }

что близко к тому, что эта конструкция призвана реализовывать в руби: [1,2,3].join

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

Если бы они писали на китайском или испанском, тебе было бы легче? %)

Я имел дело с софтом, у которого конфиги, выхлоп в консоль и логи были на испанском. Логов же было примерно сотня гигов в день.
Даже выучил пару десятков слов. :D

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

Если бы прогресс делали русские, то этим языком был бы русский. Так что стоит задуматься, кто тупой.

наличие шапки снимает необходимость нормально называть параметры?

Нет конечно, но это заставляет меня вчитыватся в код что бы силу своего разумения и загрузки текущими задачами «быстренько» разобраться в коде, аргументах и прочей требухе. Вопрос - занафига ?

А без шапки одними «правильными» именами сыт не будет и далеко не уедешь.

и соответствующее использование будет:

Мне для этого необходимо открывать код и вчитыватся ? Ибо по другому никак да ?

Комментарии на английском - зачем?

В общем случае так правильно. Чтобы код был понятен не только русскоязычным людям.

Ален Голуб в своей книге писал: «Если вы не можете сказать это по-английски, то вы не сможете выполнить это на С/С++.»

Давайте дружно писать всё по-русски!

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

ЗАЧЕМ?

Постоянная тренировка, как правило, дает плоды.

Комментарии на английском - зачем?

В общем случае так правильно

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

Ален Голуб в своей книге писал: «Если вы не можете сказать это по-английски, то вы не сможете выполнить это на С/С++.»

Может, у него просто родной язык - английский? %)

Упаси Патрег писать на русском! Помню эти жуткие ЯПы с кириллицей. кошмар!

Давайте дружно писать всё по-русски!

Давайте дружно выучим хотя бы pidgin english!

Точно, точно, Ъ именуют функции в духе brk, shmctl и экономят буквы в духе creat и umount.

ЗАЧЕМ?

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

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

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

Resolution of the Russian Federation dated May 6, 2011 N 354, paragraph 90

Recalculate the amount of payment for utilities made ​​proportionally number of days of the period of temporary absence of the consumer, which is determined based on the number of full calendar days of his absence, NOT INCLUDING day disposal of premises and the day of arrival in the living room.

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

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

Обожаю комменты и логи на португальском.

Вопрос в том, кто полезет в твой код послезавтра.

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

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

Убивать за имена переменных в одну букву!

Убивать за имена переменных больше четырех букв!

// а итераторы одной буквой называть — нормально. И координаты всякие. И регистры...

не переводи стрелки и не соскакивай с темы!:)

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

Мне пофиг.

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

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

Ален Голуб в своей книге писал: «Если вы не можете сказать это по-английски, то вы не сможете выполнить это на С/С++.»

Может, у него просто родной язык - английский? %)

:)

Как это невозможно? Я вот знаю си на уровне прочтения K&R и лаб в универе, но в строке

Зачем вы путаете реализации физмат алгоритмов расчетных задач с си-муетой общего назначения.

Никогда не писали реализации 3-4 страниц формул, да?

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

Местный биллинг в скором времени будут писать индусы.

Это прискорбно :)

То есть всех фортранщиков ?

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

И так прикинул, и эдак, ну никак концы в концами в логической цепочке не складываются

фортранщики уже сами себя наказали. им я разрешаю жить в вечных муках

Ален Голуб в своей книге писал: «Если вы не можете сказать это по-английски, то вы не сможете выполнить это на С/С++.»

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

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

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

Женятся на русской, она переведёт.

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

Если бы они писали на китайском или испанском, тебе было бы легче? %)

На русском - было бы легче.

Упаси Патрег писать на русском! Помню эти жуткие ЯПы с кириллицей. кошмар!

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

...пишет по-русски комментарии в исходном коде.

Так яснее?

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