Как стать автором
Обновить

Комментарии 212

По поводу, children — childs. Я хорошо знаю, что childs — неправильно, а правильно children. Однако, бывает, что пишу childs, потому что: 1) так короче 2) по принципам правильного оформления кода, все должно быть однообразно. А правила английского языка этому мешают :) ну почему parent -> parents, но child -> children? 3) для человека, не знающего достаточно хорошо английский язык, не будет совсем понятно, почему children — массив или множество, но название в единственном числе (то есть без s, es и т.д.).

P.S. еше встречал в коде — childrens.
Откажитесь от этого пагубного обычая.
> ну почему parent -> parents, но child -> children?

А почему «человек», но «люди»? В каждом языке есть свои особенности :-)

> для человека, не знающего достаточно хорошо английский язык, не будет совсем понятно, почему children — массив или множество, но название в единственном числе (то есть без s, es и т.д.).

Вместо того, чтобы гадать, можно воспользоваться словарём. Вообще пользование разного рода документациями и литературой — это отличительная черта хорошего инженера. Не знает языка, не пользуется словарями — ну и ссзб значит.
> А почему «человек», но «люди»? В каждом языке есть свои особенности :-)
Бендер говорил «человеков» :)
Но я согласен, что лучше всегда следовать общепринятым правилам.
Кстати уже после отпраки коммента понял, что у нас ведь тоже «рёбнок» и «дети» :-)
Ребёнок, конечно же, вот это опечатка так опечатка o_O
Зато у нас можно сказать «два ребенка» и «двое детей».
И у нас можно много чего сказать, и у них много можно чего сказать, но это уже оффтоп :-)
«Трое ребёнков» уже не скажете.
«Три ребёнка» же, «двое ребенков» тоже не скажете.
Ок, пять/пятеро уже ни с ребёнка, ни с ребёнков не сочетаются никак.
пятеро ребят
Ребята != дети. Это слово можно употреблять по отношению к группе людей лет этак до 25-30.
Ребята — это другое
Ребятишки :)
Ребят. Никогда не понимал, почему это слово конкретно к парням применяют. Да и ещё и только во множественном числе. В Большом толковом словаре Кузнецова «ребята» в смысле «парни» помечено как разговорное.
Пятеро ребятишек
Вы только что добавлением уменьшительно-ласкательного суффикса сломали «унификацию», ради которой всё и затевалось.
Согласен, со словарями, благо, нынче проблем нет. Мне часто не хватает словарного запаса для именования тех или иных сущностей в коде — всегда держу открытой вкладочку «Яндекс.Словарей» на этот случай.
Ну так кто-то из великих говорил же, что две самые большие проблемы в программировании это придумывание имён переменным и инвалидация кэша :-)
Вот, даже оригинал нагуглил:

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton
Brilliant! Это я определенно запомню :)
Я раз в полгода эту цитату мучительно вспоминаю, а потом мучительно гуглю. В этот раз наконец закинул в эверноут :-)
Я бы добавил еще предвосхищение изменений :-)
Так люто-бешено заминусовали первый комент :)
Давайте посмотрим используют ли слово childs в коде каких-нибудь не отечественных проектах. Например, Chromium:
code.google.com/p/chromium/source/search?q=childs&origq=childs&btnG=Search+Trunk

Первое попадание: libxml и т.д. и в комментах, и далее. Chromium — пример плохого кода?
Я в подобных случаях стараюсь использовать добавку list. Например, childList, mouseList и т.п.
Тут есть загвоздка. List в некоторых языках — структура данных. Так что было бы странно получить массив или таблицу из свойства childList.
childArray :)
childCollection
Сразу подумал, что написал бы именно childrenList. childList уж как-то совсем глаз режет. С другой стороны, mouseList — именно так бы записал, а не «miceList». Хм. И понял, что «child» и «mouse» — принципиально разные вещи. Одно — свойство объекта в контексте, а другое — просто название.

Child сам по себе только задает семантику иерархической структуры. А по факту, объекты обычно и сами по себе что-то означают. И поэтому получается что-нибудь вроде «subDirectoryList», и не появляется необходимости в «childList'е».
Про то, что так короче — это всё отговорки, как мне кажется.

Напоминает что-то в духе такого — «очинь спишу паэтаму пишу с ашибками». :)
> Я хорошо знаю, что childs — неправильно
>…
>Однако, бывает, что пишу childs, потому что: 1) так короче

Знаете, гадить в штаны тоже короче. Только потом вычищать дольше, если их носить хотите.

>2) по принципам правильного оформления кода, все должно быть однообразно. А правила английского языка >этому мешают :) ну почему parent -> parents, но child -> children? 3) для человека, не знающего >достаточно хорошо английский язык, не будет совсем понятно, почему children — массив или множество, но >название в единственном числе (то есть без s, es и т.д.).

Ваши аргументы не стоят выеденного яйца. Английский знает любой уважающий себя девелопер. Просто потому, что большинство документации и хороших книг по теме — на английском.
у вас их вообще нет.
Читать (переводить с иностранного на родной) это одно, а писать (переводить с родного на иностранный) совсем другое. Особенно когда дело касается исключений.
Поэтому давайте писать заведомо неправильно, так как разработчик Имярек, который плохо знает английский, не может потратить пару секунд своего времени и зайти на http://translate.google.com/. А то не поймет ведь, болезный.
Заведомо неправильно писать, конечно, не стоит. Но вот постоянно тратить время, проверяя, а не находится ли это слово в списке исключений тоже, по-моему, не тру.
Хех, прочитал, улыбнуло и вроде бы ладно, но… сегодня на CPAN откопал вот такой вот пример «совместимости»:

*wait_childs=*wait_children; # compatibility

Я плакалъ…
> почему parent -> parents, но child -> children?

Потому что у английского протогерманский в предках. И не все слова привелись к стандартной форме -s.
Совершенно согласен. Такие опечатки (и ошибки) очень отвлекают (даже мне, «izobrazhenie» — просто ад). Я когда-то читал португальскую либу, если бы хоть методы были английскими — было бы проще
Самый ад — это когда такие имена ещё и сокращают, например вместо «izobrazhenie» было бы «izobr» или «izobraz»
В копилку:
tovar,otdel,kod,sotr (сотрудник),data (кстати, удобно, т.к. не пересекается с типом данных date :),

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

image
НЛО прилетело и опубликовало эту надпись здесь
Частенько бывает как раз в госконторах, что инета постоянного нет, нужно чуть ли с Президентом РФ согласовывать если, скажем, скачать что-то нужно. И когда не знаешь как перевести какие-нибудь «закупки» или «удостоверение», то не имея доступа к онлайн-переводчикам/словарям пишешь транслитом, думая «дома посмотрю», ну а потом благополучно забываешь…
Если приходится часто сталкиваться с такими ситуациями и нет возможности поставить какой-нибудь лингво на компьютер, тогда можно обходиться словарём в телефоне/плеере.

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

В таких ситуациях я все-таки использую транслит. И да, это корп. ресурсы, англичане это читать не будут, а коллеги сразу поймут, о чем я. Хоть и не по фэншую.
еще можно izobrarzenie, на польский манер)
Тогда уже obraz, совсем на польский :)
Да и вообще языковая каша это так прекрасно.
Bonjourno! Mi amigo, wie gehts es? Czy rodzina, lou enfaunts, are on well? Та і сам ты то как? Ну давай, zai tzieñ :)
на польский манер будет через ż, rz употребляется там, где в прочих славянских языках стоит мягкое «р» — rzeka, morze, krzyk
Тогда и комментарии и вообще весь интерфейс программы делать только на английском, никогда не применяя других языков, а то немец или американец прочитать не смогут.
Интерфейс уже как-то стало нормальным делать адаптивным под множество языков, а комментарии… Ну для начала их стоит хотя бы вообще писать, на каком языке — уже вопрос «политический». Но вот когда нет комментариев вообще, а именование на смешанной тарабарщине (увы, но очень часто встречается такая ситуация), то задача читающего разобраться что к чему сильно усложняется.
Так всегда…
Не «только на английском», а «ещё и на английском». Реализация мультиязычности не самая трудная задача.
И вообще, вы берёте в пример какие-то странные крайности. Это же код, его делают на английском не потому что его не сможет прочитать американец, а потому что это «язык мира». Так его смогут прочитать куда большее количество людей, так в разработке могут принять участие куда большее количество специалистов. А если ваш проект изначально был написан с использованием таких вот названий, или что куда хуже, вообще с кириллицей, то масштабируемость штата предполагаемых сотрудников заметно падает. Да и вообще — моветон.
Думаю для большинства русскоязычных проектов международная масштабируемость разработчиков самая меньшая из проблем. Моветон и то значимей.
Дело в том, что тут даже не в международной масштабируемости дело. Даже большинство наших разработчиков, прочтя подобный код, плюнет, развернется и уйдет. Неблагодарное это дело, говнокод разбирать.
Ну я и говорю, что важнее не допускать моветон, чем думать о том, что вдруг к разработке присоединится аргентинец или кореец. Но опять же считаю хорошим тоном при нетривиальном именовании сущностей (грубо говоря, если мне самому понадобилось в словарь лезть) указывать в комментах на русском что же я имел в виду. Хотя бы чтобы через пару месяцев самому не лезть в словарь, чтоб смотреть что я там выискал при написании.
Если проект, конечно, ориентирован сугубо на российский рынок и участие иностранцев не предполагается.
А вы разве не так делаете? Что уж поделать, английский в программистской среде — lingua franca.
НЛО прилетело и опубликовало эту надпись здесь
>...izobrazhenie… Что будет ощущать англоговорящий разработчик, читая этот код?
Он будет искать класс zobrazhenie, который реализовывет этот странный интерфейс.
> идеальным вариантом было бы назвать метод getChildren.

Не всегда. В разных языках/техниках/проектах приняты разные принципы именнования get'еров. Где-то принято с get, а где-то без.
В данном случае речь о php, если уж оно свойство — то без, если метод — то с get. Если свойство реализованное через магический метод, то и то и другое (если используется отдельный метод, вызываемый из магического). Большинство стандартов кодирования подразумевают такую логику именований.
Большинство но не все, а единого стиля нет в принципе.
Ясно, что автор говорил о части после «get» (т.е., getChildren, а не getChilds).
Читабельность — одно из самых важных свойств хорошего кода. Если не самое важное. Мы тратим на чтение кода гораздо больше времени, чем на его написание. Потому лучше посидеть чуть подольше и написать читабельный код, зато потом гораздо больше времени уйдет на его чтение.
Кстати, комментарии на французском — не проблема. Проблема — комментарии вообще. Если их много, значит сам код, скорее всего, не читабельный.
Опечатался: меньше времени уйдет на чтение.
Боюсь спросить: за что минус в карму?
Я однажды видел PHP-код, прокомментированный до такой степени, что я (с очень худым знанием PHP (и незнанием что такое curl)) всё прекрасно понял.
Соглашусь, что читать комментарии проще, если плохо понимаешь язык синтаксически. Но в высокоуровневых языках сам код может выглядеть как повествование. Описательные имена переменных и методов, небольшой размер метода и соблюдение одного уровня абстракции в его пределах — все это способствует тому, чтоб код читался, как книга.

Например, если мы видим строчку кода:

var pageHtml = downloadWebPageHtml(pageUrl);

Нужен ли нам комментарий, чтобы понять что здесь происходит? Я думаю, что нет. Комментарий только создаст лишний шум.

Предлагаю рассматривать язык программирования, как лингвистический язык изложения мыслей, а не язык конструирования алгоритмов. (И не только я предлагаю).
Если так его рассматривать, то становится понятно: если человек не знает самого языка программирования, то нечего ему и читать код. Нет смысла читать и понимать код по комментариям. Домохозяйкам и сантехникам это не нужно. Даже если они поймут, они не смогут править и чинить.
Поэтому я следую такому интуитивному правилу: код должен быть понятен, но без комментариев. Если при написании кода «просится» комментарий, значит следует посмотреть еще раз код, что-то в нем возможно не так. А уже потом, по остаточному принципу, писать комментарии (бывают и сложные алгоритмы или оптимизации, которые делают код не очевидным).
Конечно, эта логика не относится к описанию интерфейсов (или просто методов и классов).

Язык программирования — язык выражения мыслей. Если у человека не получается с ним так работать, он начинает выражать мысли на других языках — естественном или UML или не важно каком.

Во всех других языках есть существенный недостаток — их гораздо тяжелее поддерживать адекватными текущей реализации. Потому что самый честный товарищ, объясняющий, что делает код — это код. Во вторых это дублирование логики и по сути двойная работа. Так что лучше минимизировать комментарии, насколько это возможно, не теряя читабельность
Припоминаю, игрался когда-то с исходниками Doom'а. Так вот, там — а они американцы! — было VERTEXES, при правильном vertices.
Как и в случае с indexes/indices, возможны оба написания: и vertexes, и vertices. Пруф 1, пруф 2.
My Sire, we accept no english, but the Royal one :)
Well, in that case, why did you capitalize «sire» and «royal»? Shakespeare didn't do that. The word «English», on the opposite, must always be capitalized.
FYI, «indices» and «vertices» are not, in fact, English words, they are Latin.
Oh, thats a pretty old school, straightforward way of Monty Pythoning: playing a snobbish Englishman, accepting no English language, but that used in England. England, not UK, GB, Ireland etc. And the rest is just oversnobbing :)
London is a capital of Great Britain.
the capital
True gentleman thread it is.
Вы еще представьте британский код с colour, judgement вместо judgment и getConnexion() вместо getConnection()
НЛО прилетело и опубликовало эту надпись здесь
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /index.php
Кошеrно!
Сомневаешься в правильности написания названия переменной?
Назови ее просто: asd123.
И с утра вспоминай нахрена она вообще нужна.
а для этого можно каждый раз писать что в ней будет храниться).
еще и tmp, tmp1, tmp2, tmpArray. ща насобираем вредных советов
Еще можно i,j,k. Главное, чтобы они не имели ни малейшего отношения к индексным переменным :)
Плотно работая с немецким коллегой договорились комменты (кроме тривиальных phpdoc и т. п.) писать на родном для каждого языке, причём соблюдая (стараясь соблюдать) все правила грамматики и избегая (стараясь избегать) всяких «сложноподчиненных деепричастных оборотов» ©, но сущности именовать на английском, причём тщательно проверяя в словарях прямой и обратный перевод. Причина первого — онлайн-переводчики не очень адекватно переводят с немецкого на русский или наоборот через английский, напрямую куда лучше.

То есть если я перевожу с русского на английский через, скажем, гугл, то на мой взгляд вполне корректная английская фраза получается, и даже на при переводе её обратно на русский получается более-менее понятно (мне :) ). Но он говорит, что на немецком полная абракадабра получается при переводе английского перевода. Если же он переводит с русского на немецкий напрямую, то говорит, что более-менее понятно. Аналогично с его стороны.

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

Насчёт именования: Однозначно на английском, но если пришлось лезть для этого в словарь или переводчик (то есть слово не распространенное в программировании), то тщательно проверять обратный перевод. А то может получится так, что прямой перевод на английский русского слова однозначно обратно не переводится и «оригинал» далеко не самое распространенное значение. Иногда по 15 минут приходится подбирать пару «русский» — «английский», чтобы использовались самые распространенные значения в обоих языках.
Как-то сложно у вас всё. Не проще ли знать один общий для всех программистов язык и писать комментарии на нём? Вы же не роман там пишете — терминология всем знакомая, чудес грамматики от комментариев не требуется. Да и комментарии должны пояснять код, только когда это действительно нужно. Вот что я написал сегодня:

    //--- Check SD version and voltage range ---//

    enum {
        DESIRED_VOLTAGE = 0x01, // standard voltage range: 2.7 - 3.6 V
        CHECK_PATTERN = 0xCC
    };

    card->spi->SelectSlave(card->spi);
    send_command(card, CMD_SEND_IF_COND, (DESIRED_VOLTAGE << 8) | CHECK_PATTERN);
    R1_response = read_R1(card);

    if (!R1_is_valid(R1_response))
        goto ERROR;

    if ((R1_response & R1_BIT_ILLEGAL_COMMAND) == 0) {
        uint32_t R7_response = read_R7(card);

        uint8_t pattern = R7_pattern(R7_response);
        uint8_t voltage = R7_voltage(R7_response);
        uint16_t reserved = R7_reserved(R7_response);
        uint8_t version = R7_version(R7_response);

        if (pattern != CHECK_PATTERN || voltage != DESIRED_VOLTAGE || reserved != 0 || version != 0)
            goto ERROR;

        card->props.version = SD_VERSION_2X;
    }
    else
        card->props.version = SD_VERSION_1X;

    send_padding(card);
    card->spi->ReleaseSlave(card->spi);

Без тени гордости считаю, что именно так и нужно писать код — тогда и не придётся ломать голову над комментариями. А у вас в проекте получается туча комментариев минимум на двух разных языках. Да ещё, если я правильно понял, вы не брезгуете шаблонными комментариями в стиле:

    /// Возвращает число соединений с базой данных
    size_t Database::getConnectionCount() const
    {
        ...
    }

Или я как-то не так понял значение выражения «тривиальные комментарии»? (:

Google Translate — это вообще за гранью добра и зла: им можно проверять правильность фраз не сложнее «моя твоя ходить кино», т.к. этот сервис не в курсе грамматик языков (см. стенфордский курс по ИИ).
Когда будут какие-нибудь мнемотрансляторы, транслирующие знания прямо в мозг, тогда, вероятно, будет проще. А пока не встречал эффективных средств самостоятельного изучения английского. Словарный запас полнить можно, а вот грамматику на уровне хотя бы школьного сочинения…

На трёх языках комментарии, типа:
/**
 * Database wrapper
 **/
class Database {
  /**
   * Return the count of database connections
   *
   * @return int count of database connections
   **/
  public static getConnectionCount() {
    ...
    // Тут мы используем алгоритм пузырьковой сортировки. Прямой перебор показал свою неэффективность. 
    ...
    // Geben Sie Ihre Meinung über die Besonderheiten der deutschen Sprache.
    ...
  }
}



Когда пришли к подобному соглашению намного меньше приходится общаться на ломаном английском (у обоих) чтобы понять, а что собственно имелось в виду. И пускай Google Translate не в курсе грамматик, нам главное чтобы мы друг друга понимали, в этом он помогает, причём лучше помогает когда английский не используется в качестве «внутренней кодировки».
> А пока не встречал эффективных средств самостоятельного изучения английского.

Было бы желание. Очень неспешно учил по книжке Реймонда Мёрфи, параллельно закрепляя изученное на stackoverflow
«Закрепляя изученное на stackoverflow» это как?

У меня лично проблема такая — я придумал предложение по-русски, сделал его грамматический разбор, посмотрел как какие части выражаются по-английски, написал «каркас» предложения (все эти the is to и т.п, которых в русском как бы нет) и под конец перевёл значимые слова. Но вот уверенности, что всё правильно сделал, нет. Пишешь-пишешь, а правильно или нет не знаешь. А понимание, что неправильное написание всё равно закрепляется где-то в подсознании как-то отбивает желание писать вообще. Вспоминается сразу вспоминается Паганель, выучивший язык по «самоучителю».
> это как?

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

> Но вот уверенности, что всё правильно сделал, нет.

Нужно начитывать «паттерны» в книгах. Ну и особо проблемные предложения можно давать проверять на том же english.stackexchange.com

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

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

Но фидбэка же не получаете, правильно вы пишите или нет?

>можно давать проверять на том же english.stackexchange.com

Спасибо за наводку, в закладки.

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

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

С программированием проще. Синтаксические ошибки ловит транслятор, а «грамматические» тестирование или багрепорты.

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

Мне не страшно ошибки совершать, мне страшно совершать их и не знать об этом. То есть буду уверен что я пишу правильно, а из вежливости и корректности мне на ошибки указывать не будут (уже не раз сталкивался).
> Но фидбэка же не получаете, правильно вы пишите или нет?

Естественно нет. Но:

1. На то оно и самостоятельное обучение
2. Программировать вы (и я) учились так же, постоянно наступая на грабли. Наступание на грабли — и есть обучение :-)
3. Нужно наработать моторику на применение грамматик и расширение активного словарного запаса.

> С программированием проще. Синтаксические ошибки ловит транслятор, а «грамматические» тестирование или багрепорты.

Не проще — есть «лучшие практики», паттерны, оптимальные и неоптимальные способы написания. Это всё не ловится ни компиляторами, ни тестированием, ни ещё чем-нибудь, это всё опыт.

> Мне не страшно ошибки совершать, мне страшно совершать их и не знать об этом. То есть буду уверен что я пишу правильно, а из вежливости и корректности мне на ошибки указывать не будут (уже не раз сталкивался).

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

Потому — нужно просто больше и внимательнее читать и сравнивать с тем, что пишешь сам. В английском куча языковых паттернов, которые нужно просто наговорить до уровня «применяю не задумываясь», а это практика + изучение грамматики.
Начитывание «паттернов», кстати, один из лучших способов выучить английский язык. Есть даже бредовые книги с готовыми десятками тысяч готовых фраз %) А пытаться находить соответствия между частями речи различных языков или учить правила со странной формулировкой нудно и долго. И книги Мёрфи реально клевые для чтения: предложения из жизни, «как надо» вместо правил и написана носителем языка. Результат будет через несколько месяцев. Главное, выполнять все упражнения и понять каждый юнит из книги.
Следует переучить англичан говорить childs. Множественное: единственное + 's'. А все исключения оставить для высокопарного литературного стиля.
И научить вместо «image» употреблять «izobrazhenie»?)
Вам в руки esperanto — с простой лексикой и правилами без исключений
Даёшь язык программирования на esperanto)))
В алфавите эсперанто используются диакритические знаки, что делает его малопригодным в качестве базы для ЯП.
Наиболее современные языки позволяют использовать в идентификаторах практически все буквенные символы Юникода.
Позволяют, но не сказал бы, что это очень удобно.
Для отображения нужен шрифт с поддержкой этих символов, для ввода — дополнительная раскладка клавиатуры.
Разве что, как компромисс, заменять «проблемные» буквы на диграфы.
В эсперанто можно обойтись и без циркумфлексов, это было продумано при создании языка: Ĉ -> cz и так далее.
Проблема s в конце для слов во множеством числе решается элементарным образом. Пишется слов в единственном числе, далее следует суффикс list.
$children_list = getChildrenList() {...}
foreach ($children_list as $children) {}


Получаем следующие профиты:
1) s в конце это один символ, визуально при чтении кода такой нюанс можно пропустить, слово list более нагляден (в примере выше это видно в foreach-е);
2) не нужно думать о правилах образования множественного числа, добавить в конце слова тупо s можно не всегда;
3) уходят проблемы для слов подобных news:
$news_list = getNewsList() {...}
foreach ($news_list as $news) {}


list — всегда массив. Методы при этом всегда должны возвращать массив, переменные всегда содержать массив.

Следование этому правилу упрощает поддержку кода даже в случае единственно разработчика.
С news, да, постоянное мучение. Стал использовать newses :)
Совет работает до тех пор, пока не встречается язык, в котором есть разные типы коллекций список и массив, и тогда «list — всегда массив» будет только портить.
Безусловно. К примеру, в erlang-е я бы так писать не стал. Но в PHP деление на массивы и не-массивы работает и там подобная схема применяется вполне эффективно.
А я вообще избегаю суффикса 's' ('en' — тем более) в названиях переменных. Вместо этого по давней привычке использую «венгерскую» приставку 'a':
$a_child, $a_news

А для функций/методов использую суффикс 'set':
getChildset(), getNewsset()
Даёшь переводчик кода :)
НЛО прилетело и опубликовало эту надпись здесь
>Программисты 1С
Всегда пользуюсь переводчиком или словарем, когда не могу подобрать нужное слово по-английски.
Ради юмора я как-то написал забавный класс на PHP и применял исключительно кириллицу, где это было возможно.

class Чайник {
const ВРЕМЯ_КИПЯЧЕНИЯ = 300; //сек

public function Включить () {
//…
$this->_ВыключитьАвтоматически();
}

public function Выключить () {
//…
}

private function _ВыключитьАвтоматически() {
//…
}
}

В общем враг не пройдёт )))

P.S.: естественно, это НЕ «боевой» код, но вполне рабочий )))
Вполне нормально, и без юмора :)
прошу прощения за оформление, source lang=«php» почему-то не применился.
карма в минусе :(
В принципе идея понятная. Но я бы все же предпочел называть переменные и классы кириллицей на русском, не каждый язык позволяет. Подстраиваться под английскую культуру — зачем?
Впрочем сам я так не делаю :), написал и подумал — что замахаешься языки переключать — проще на английском написать. Но это лишь означает, что нужна более удобная поддержка написания на родном языке.
> Подстраиваться под английскую культуру — зачем?

1. Так писать быстрее — переключение раскладки будет занимать тонну времени
2. Потенциальные проблемы с инструментами для разработки
3. Английский программисту просто нужно знать (спорно, согласен, но тем не менее)
Действительно, сам написал выше про переключение раскладки. Но эта проблема решаема в перспективе, думаю тут нужно что-то типа автоматизированного словаря с интервики ссылками (что-то типа Викисловаря — ru.wiktionary.org), но заточенного под компьютерный сленг. Тогда среда разработки (та же Visual Studio) должна его интегрировать. Тогда текстовый редактор может автоматически заменять (переводить) операторы и названия переменных в зависимости от родного языка программиста. Это конечна далекая перспектива, но если не ставить задачу, а вместо этого ассимилироваться/ассимилировать свои продукты под английскую культуру — то это вырождение своей культуры, в которой есть не мало хорошего.
Под какую «культуру»? Именовать переменные на русском языке — вы это называете культурой?

В чём смысл идти против всего мира?
Не просто именовать. Ведь если бы речь была в простом именовании, то как предлагалось выше можно было называть переменные abc123, и успокоится. Вместе с именованием, мы хотим понимать семантику происходящего в коде. Как можно понять сложную семантику на не родном тебе языке?
Семантика происходящего — это десяток управляющих структур языка программирования и служебные символы.

Львиную долю сорсов занимают элементы, созданные программистом: имена переменных, имена методов, имена классов, имена функций, имена структур, итд итп.
Ну, смотрите. Когда вы пишите A.B() — вы ничего не знаете о семантике. Так? Именно поэтому так плохо использовать плохое именование. Когда же вы пишите Будильник.Выключить(), вы читая замечательно понимаете семантику. Так вот семантика заключается в ясном и четком наименовании переменных, методов, классов… Зачем мне создавать семантику не на родном языке, и выступать постоянно машинным транслятором?
Я вас ниже спросил, каким образом ваш код «Будильник.Выключить()» будут поддерживать друзья из Индии. И как вы будете поддерживать их код.

Кто автоматически переведёт имя переменной «будильник» и имя метода «выключить»?
Переведет среда разработки (например, VisualStudio, и любой встроенные в него продукт addin)
Каким образом? Вы пробовали хотя бы раз в жизни читать текст, переведённый автоматически?

Предлагаю вам «поработать» автоматическим переводчиком и перевести на русский вот такой вот код:

var state = "";
Я же не предлагаю использовать переводчики естественного языка. См ниже более точное предложение. Я не вижу проблем в его реализации.
Пожалуйста, переведите мой пример на русский язык. Ведь это простой процесс, как вы утверждаете.
переменная состояние ="";
Неправильно, не «состояние», а «штат».

О какой семантике вы говорите вообще, если даже человек не может корректно перевести?
:) Вот вы считаете, что из-за того, что есть многозначность слов — это проблема сложная. Нет. Это проблема есть только в естественных языках.

Вот подумайте сами. Пишут два английских товарища, им переводить не надо. Один напишет

var state = ""; // и подумает что это «Штат»

А второй прочитает var state = ""; // о состояние!

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

А теперь прочувствуйте мое предложение, на этот случай в словаре будут два разных именования

state_1 — переменная // на русском и английском комментарии какой смысл используется
state_2 — штат // на русском и английском комментарии какой смысл используется

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

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

var state = ""; // и подумает что это «Штат»

А второй прочитает var state = ""; // о состояние!


Эти товарищи знают контекст. Они могут посмотреть в документацию или на пару строк ниже.
Не знают они ничего. Они лишь могут смутно догадываться — или спросить друг у друга. То-то я рефакторя один проект, скаченный из нета, много могу посмотреть документацию, которой нет: )
Знают они, они пишут программу для голосования в США.
Ага, а состояния выборов у них нет, а них есть только штат выборов :)
Это вершина айсберга «контекста». Контекст определяется не только предназначением программы, но и текущим классом, методом, переменными вокруг.
и да великая сила раскраска слов, так вот часть state имеет нормальный черный цвет, а идентификатор смысла "_1" — бледно серый. Код набираем как и следует используя «умные подсказки», только если в VisualStudio при именовании новой переменной «мастер подсказок» злобно молчит, тут просто должен предлагать имеющиеся слова из словаря, и при отсутствии таковых — злобно показывать ошибку компиляции, и предлагать ее исправить. Прикидываете как быстро тогда миллион программистов создадут все нужные им переводы.
причем переводы в однозначном смысле.
Т.е. вы считаете семантичным добавление _1?

> Код набираем как и следует используя «умные подсказки», только если в VisualStudio при именовании новой переменной «мастер подсказок» злобно молчит, тут просто должен предлагать имеющиеся слова из словаря, и при отсутствии таковых — злобно показывать ошибку компиляции, и предлагать ее исправить.

Т.е. теперь кроме программирования я ещё и переводом должен заниматься, чтобы хоть как-то понимать код?
Вы смешно обсуждаете, нет честное слов. Типа а так статья переводом заниматься не предлагает :) Прочитайте статью, автор целенаправленно предлагает переводить все на АНГЛИЙСКИЙ язык, а для этого кроме того, чтобы мне заниматься программированием он предлагает знать ВСЕ ньюансы английского языка, и мой родной язык приводить к их грамматическим формам.

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

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

И да, "_1" + подсветка комментария о семантике, является более чем семантическим добавлением, особенно в условиях ПОЛНОГО отсутствия семантики.
> Типа а так статья переводом заниматься не предлагает :)

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

> а для этого кроме того, чтобы мне заниматься программированием он предлагает знать ВСЕ ньюансы английского языка

Не предлагает. Для именования переменных достаточно знать примитивные основы и уметь пользоваться словарём.

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

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

> И да, "_1" + подсветка комментария о семантике, является более чем семантическим добавлением, особенно в условиях ПОЛНОГО отсутствия семантики.

Семантика в исходном коде есть, она определена контекстом и именами. А вы, не зная этого контекста (автоматически вы его не определите), предлагаете добавлять суффиксы с нулевой смысловой нагрузкой.
Смешно. А общий язык у нас будет — английский :) А всех кто его не знает — будет некомпетентен. Весело.

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

Еще даже не начал кодировать а со всех сторон не компетентен :)

А суффиксы не с нулевой, а с полноценной! (она описывается в комментарии подсветки, никогда в студии не набирали код? Не видели как выбирая имя метода описывается, что он делает? )
В общем и целом — я не настаиваю, продолжайте мечтать дальше :-)
В порядке бреда:

var _(«state», «geography») = "";

и рядом пачка .po файлов.
Т.е. от читабельного и простого кода мы переходим к код в стиле Капитан Очевидность?
Нет не предлагаю. Но единственный способ адекватно переводить переменные (я не говорю о смысле этой фигни) — это вводить gettext и учить ide скрывать _() за человеческой фразой. В комментариях же есть сторонники этой точки зрения.
Сторонник предлагает автоматический перевод. А у вас предложение — вручную переводить все ваши переменные.

Решения принципиально разные: решение сторонника будет переводить неправильно, а вы, вместо программирования, будете заниматься переводами.
похоже вы не сильно то хотите понять собеседников.
Если бы я этого не хотел — я бы не участвовал в этой дискуссии. А вы снова делаете ошибочные выводы, не имея достаточно контекста (как в примере со state)
А собственно какая разница если я пишу что-то про будильник буду я сам смотреть в гугл транслэйте слова «будильник» и «выключить» или это сделает умная IDE/редактор? Это уж если благодаря какому-то невероятному стечению обстоятельств мой будильник будут поддерживать индийцы. Или ваш пример со state — какая разница кто переводить будет, если оба переведут неправильно? :)
Человек переведёт правильно — у него контекста несравнимо больше.

Вы пишете программу конвертер размеров нижнего белья. Этого контекста вам хватит, чтобы перевести «cupSize» как «размер чашечки», а не «размер чашки» или «размер кубка».
Видите ли, конечно объем и первенство компьютерного рынка захватил английский язык. Но это проблема, а не стоит к ней относится как к должному. Иначе бы MSDN никогда не переводили бы на русский, русских Window или сред разработки, таких как VisualStudio, и всех прочих продуктов, где добавляется суффикс RUS — просто бы не было. А лет 10 назад почти так и было — мои знакомые считали когда-то очень чудным ставить себе русский Виндоус или Офис, ну а что же тут чудного. То же самое мы теперь имеем — идя этот путь дальше… его нужно просто грамотно пройти, а не ложится под английский язык…
Вы перегибаете палку. Одно дело — переведённый продукт, другое — переведённый язык программирования.

Как вы представляете процесс поддержки ПО, которое было написано друзьями из далёкой Индии на родном языке?
Очень просто. Вы не этого не заметите, будет осуществлен автоматический перевод, причем достаточно легко (в отличии от естественного языка), т.к. друзья из далекой Индии, будут пользоваться теме же терминами, что и мы, только они на своем языке, а мы на своем (а соответствие будет проставлено аналогами интервик, знающими два языка).
Эм, каким образом имена переменных с индийского будут переведены на русский? (это не конструкции языка, их тем же парсером, что разбирает программу, перевести не получится)

В каком виде должны храниться исходники?

Что будет с диффами в системах контроля версий?
Вы в курсе, что такое Викисловарь и используемые там интервики?
Я задал три вопроса.

И, да, я в курсе, что такое викисловарь.
1. уже сейчас есть гаджет, который в вики, используя викисловарь при наведении на англ. слово дает перевод. Что мешает индийскому коллеги использовать слова из викисловаря, а VisualStudio перевести с индийского на русский (используя установки пользователя)

2. В любом. Там могут хранится вместо слов идентификаторы слов вида «будильник» = c103hf45, а «выключить» = m567483gr

3. Дифы будут работать также, только при выводе пользователю в зависимости от установок будет выполнен авто перевод идентификаторов на требуемый язык.

(предвосхищая вопросы: словарь пополняемый и конечный, и не имеет той сложности которая есть в естественном языке. поэтому указывать на то, что это сложно — не стоит, это на порядок легче чем существующие переводчики естественного языка)
> это на порядок легче чем существующие переводчики естественного языка

Это на порядок сложнее, потому что ошибка в тексте приведёт к непониманию, а ошибка в трансляции — к ошибке в программе (которая вызовет дальнейшие ошибки или вообще сломает всё). Хотите ещё примеров, их есть у нас:

var color, colour; — переведите на русский.

var cup; — переведите на русский

var чашка, кубок; — переведите на английский
Ну, что вы в самом деле. Разве сложно составить соответствие между 5 словами?

var — переменная
color — цвет

и т.д.
А вы всё таки переведите, пожалуйста. Я вам показал валидный код. Покажите его валидный перевод.

А в случае с `var cup` — попробуйте угадать корректный перевод без контекста, я в этом месте пожелаю вам удачи.
Выше я написал, что это не вопрос перевода. Там же конкретное предложение.
Выше вы опять перешли на софистику.

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

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

А человек, да, в контексте понять может.

ps: ваше «конкретное предложение» я не понял. Отдельные слова я, безусловно, понимаю, но общий смысл от меня ускользает.

pps: я вам дал несколько примеров, но вместо демонстрации на них — вы по каким-то причина решили использовать свои, которые, очевидно, обходят углы, на которые я вам попытался указать.
Проблема в том, что вы все усложняете. И поэтому не понимаете. Нету никакого контекста в наименовании. Контекст появляется позже. Вы вначале даете просто однозначное определение, ориентируясь на свой родной язык. Если такого термина (а кроме терминов, при наименовании ничего не нужно!) еще нет, вы пополняете словарь. Языковые специалисты находят соответствия и проставляют интервики. Все, программка для студента
В именовании контекст есть. Мой пример со state это более чем красноречиво продемонстрировал.

Я не усложняю, я смотрю с жизненной позиции, а не со сказочной. Всё, что вы говорите, бывает только в Воображляндии. Реальный мир намного сложнее.
Нет, ваш пример со state ничего не показал. И более того я его легко разобрал.
Нет, вы ошиблись в переводе.

И ваш код вместо логичного и корректного (вы ведь за это сетуете?) стал некорректным и непонятным.

Вот вам ссылка на ваш ответ с ошибкой: habrahabr.ru/post/143716/#comment_4821468
Это не я ошибся, как вы не понимаете. Это вы просто не воспользовались предлагаемым гипотетическим инструментом. А должны были в самом начале выбрать из словаря нужный семантический смысл, с нужным суффиксным идентификатором.

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

Вы вводите слово state по буквам, аналогично тому как в студии в низу мастер подсказок ищет подходящие. Набрали. Внизу остался список из 10 вариаций значений state — вам остается лишь выбрать тот, который вы имели введу. Аналогично тому, как есть полиморфизм методов. Что тут сложного, непонятного?
Мы вроде говорили о поддержке **уже существующего кода**.

Вот к вам приехали 10мб сорсов на индусском. Они компилируются, программа даже работает, но ничего непонятно.

Дальше что?
Нет, мы говорим о технологии будущего :) И естественно, так нужно писать новые программы. Или если нужно делать языково-смысловой рефакторинг (о, уже и термин готов: ) ) старого, если сложно понять что зачем, и ведется международная разработка.
Окей. Т.е. всё ещё более сказочно, чем я предполагал. Окей :-)
Ну, и в чем тут сказка? Вполне реально все сделать.
Этот стандарт нужно будет навязать всем. Это невозможно, это и сказочно.
Не всем, а только тем кто захочет использовать этот продукт :)
Если же 10мб сорсов на индусском, были УЖЕ написаны на новой платформе, то они легко просто переведутся на требуемый язык.

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

Проведите опрос здесь же на хабре, чтобы убедиться, что это никому не нужно.
Тут, я не сомневаюсь. Я же говорил в самом начале, кому то вначале не нужны были и русифицированные продукты.
Спасибо за минусы. Очевидно, что моё мнение «Ваша идея нежизнеспособна» не имеет права на существование.
Да, ладно, вам. Если бы вы написали бы свое мнение более мягко и немного обдумано, то и реакция был другая бы.

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

Придётся навязывать всем использование этой технологии. А у некоторых или окружение специфическое, или нет плагинов, или корпоративные стандарты,…
Всегда хорошо, когда есть альтернатива. Как только напишем такой продукт, будет выбор: или использую наш продукт за 5.99$ или учите английский. И еще вопрос, что будет выгоднее фирме. И идею дарю, может кто и заработает на этом :)
И согласитесь быстрее программисты будут пользоваться единым продуктом, чем все выучат английский.
Не соглашусь :-) Для программирования нужно знать всего ничего. Миллионы программистов, которые не знают языка, это доказывают.
Они лишь доказывают, что могут красиво и с юмором именовать data_of_zakupki © :)
Если это их не парит — то и продукт им такой не нужен, потому что всё и так им понятно
Причем если вы укажите, что вам милее английский :) — пишите на нем. По этому пути пошли даже языки программирования, ведь в самом деле отличия между языками (C#, VB, и т.д.) лишь в их синтаксисе, все равно это все транслируется в машинные коды. Поэтому тут надо просто обеспечить удобство человеку, а разница в синтаксисе языка программирования или родном языке программиста — это лишь технические детали. 21 век увы ;)… и мы идем все дальше, так не нужно же мыслить как пещерный человек с палкой в руках и 10 звуками, который или защищает свою самобытность («национализм») или подстраивается под раннего европейца, который впервые написал его звуки латиницей («ассимиляция»)… нам нужно решение более тонкое и продвинутое.
Покажите пример того, о чём вы сейчас говорите. Ваше текущее «тонкое и продвинутое» предложение без примеров — не имеет никакого смысла.
Ну, я же не говорю что у меня есть реализация. Так ведь? Я говорю (ставлю задачу) о том как это надо сделать.
Ваше текущее предложение выглядит как «давайте всё переведём». Без конкретных идей и предложений.

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

Английский для программистов — та же латынь для медиков и фармакологов, помогает устранять барьеры между странами в профессиональном общении, что в целом позволяет индустрии развиваться быстрее.
В далеком 1995 (в школе еще) изучая TASM 1.0 ужасно мучился с именованием переменных, товарищ решал проблему проще — @1, @2, @3...., еще было совсем не понятно, зачем делать отступы в коде. Теперь же когда вижу код с переменной izobrazhenie или, (не дай бог!) не корректные отступы — все, спазм мозга…
Программирование нужно начинать изучать с питона — тогда с форматированием проблем не будет :-)
Промахнулся, ответ ниже
Да полностью согласен, я сейчас всячески продвигаю идею использования питона в качестве первого языка в вузе, вместо турбо паскаля — морально устаревшего еще в прошло веке.
Но — python-style завершения блока меня честно говоря немного напрягает, C-style имхо лучше. И это единственное, с чем сложно согласиться, все остальное в питоне доставляет удовольствие.
Хотя, кстати, многие новые C/C++ библиотеки используют питон стиль, тот же argtable например.
Как-то видел одну итальянскую вещь, там были захардкожены итальянские Program Files: «C:\Programmi» :)
НЛО прилетело и опубликовало эту надпись здесь
Т.е. переименовывает перед релизом? Рисковый парень.
А как на счёт сопровождения кода потом, а? Открывает исходник — а там всё не так как было раньше… ох!
Так все просто же, реверс-перевод потом и изменяет %) А вообще не верю, что так проще. У меня на beginner уровне не было проблем с именованием функций и переменных. Пусть названия и были кривые и не всегда правильные слова было выбраны, но они были на английском и код можно было понять.
НЛО прилетело и опубликовало эту надпись здесь
С ходу не могу представить себе более-менее серьёзную программу, которую не надо доделывать после релиза, хотя бы минимально.

«Кошка бросила котят — пусть е**тся как хотят» — не мой выбор.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» — Мартин Голдинг. Если об этом помнить то с именами будет попроще.
А еще есть подход, утверждающий, что правильные имена переменных и функций заменяют 95% комментариев.
В umi cms когда создаешь свойство, необходимо написать его название для отображения в админке. Соответственно пишешь русскими буквами, а название латиницей автоматом переводится в транслит. Часто забываешь сменить название на нормальное, и если это свойство в кастомных методах не пригодится, то быть ему так названным неопределенное время. Вот отсюда и izobrazhenie
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории