Есть ощущение, что в мире, в одночасье, будет разрушено очень большое количество сообществ, тем или иным способом базирующихся в Twitter. Кому Маск не по душе, а у кого возникнет стойкое ощущение, что город наступил на их дом, ну, как в фильме "Пустота" Винченцо Натали...
Я вот так в чат организации написал, что вот - средние зарплаты. А меня шапками закидали, мол фигня, а не расчёт, мол один с зп в 2кк и остальные за 20ку. Показал, что - нет коллеги, вот медианы, вот перцентиль - не поверили.
Да, как начинаешь думать: чтобы себе сделать анонимную личность, нужно сим-карту левую (чтобы личность не твоя), телефон новый (чтобы текущий не спалить), поехать с ним и ноутом (желательно не твоим) в лес за 200 км (потому что вышки же и чтобы рядом телефона и быта твоего не было), а потом пользоваться только через vpn, да еще желательно в людных и разных местах, и т.д.т.п. Желание в этой личности пропадает.
Как в сериале "Полицейский с Рублёвки": "Да как они нас найдут?". "А фиг его знает, как мы их находим?"...
Я подозреваю, что автор имел ввиду, что если мы члены класса называем с префиксом my_, но при этом член класса - поле булевского типа (которые, по задумке автора стоит именовать с префиксами is_ или has_), то получается каша. Если принять во внимание Ваше предложение, получается, что для натуральности кода как языка - отлично, для понимания: что перед нами, переменная, поле класса, какого типа - неоднозначно.
Да, есть еще контекст, но тогда система его вроде не работает, получается))
За что я люблю Хабр и рад стать частью этого комьюнити. В комментариях, зачастую, можно найти огромное количество полезной информации и именно из-за Хабра я стал больше читать комментариев, под разными постами, на разных ресурсах.
Вам огромное спасибо за способ записи. С разбега сразу не гуглится. На Вашем примере отодвинул бы правые скобки к третьей строке, чтобы в глаза сразу бросился параметр функции. Простите за душность))
По поводу стилистики наименования элементов в разных языках — немного отдаёт самозатворничеством. Не считаю моветоном использование в своей программе стилистики, которая устраивает меня. Оговорюсь, что это не касается продуктов, которые разрабатываются командой, особенно там, где есть соглашение о коде. В своих работах пользуюсь подчёркиваниями в abl, в том числе (в Java пробовал - нормально выглядит). Хотя в abl чаще пользуются вообще, венгерской нотацией.
Как и большинство изучающих языки программирования, стараюсь читать документацию. Если в документации, создатели языка говорят о регистронезависимости операторов или ключевых слов - я пользуюсь этой информацией. Ну, скажем так, я не адепт больших букв в запросах к БД. Когда погружен в язык, нет необходимости выделять ключевые слова прописью, особенно с текущим уровнем различных редакторов и IDE. Да, есть огромное количество мест, где: не то, что цвета, вообще вёрстки толком нет — но и там, я знаю, большие буквы в select'е не становятся панацеей для удобства. Всё равно придётся прочитать всё, чтобы понять, что происходит, если код не твой. Если твой, то точно: большие буквы в тексте не ускорят процесс понимания и фиксации. Надеюсь, понят правильно.
Насчёт реформаторов - полностью с Вами согласен. Оригинального мало, но есть полезное. Я не защищаю, в данном случае Коэна Уиттерса, ну просто для себя нашёл некоторые полезные моменты, которые применил на практике.
Было бы интересно посмотреть, кстати. pylint с 2004-го существует, статья 2009 года. Возможно тогда у них была какая-то синхронизация. Но, вопрос интересный.
Про операторы - это ко мне больше. Текст и так был большой, где-то его можно еще сократить, но не хотел отходить от оригинала. Я думаю, если поменять в этом тексте слово "оператор" на "ключевое слово", смысл не особо изменится.
В угоду лучшей видимости кода автор, всё же пренебрёг правилом "должно быть как естественный язык", тем более, что он поясняет это целостностью оператора (функции), в случае, если "прилепить" скобку к ключевому слову (имени функции).
Ну вот, например, из последнего:
Рис.1: Код на abl с некоторыми методами описанного стиля
Про организации - сто процентов, Ваша правда, но подкорректировать личный стиль кода никто не мешает. На скриншоте тоже видно, что у меня нет возможности быть "адептом стиля deWiTTERS", но что-то можно использовать. Вы же не используете стиль кода, которым писали в своей первой организации, во всех последующих?
А про изменение кода - это его профдеформация, как программиста. Я, например, часто не могу пройти мимо кода в продуктах своей организации, если там откровенный колхоз. Ну, правда, не всегда получается прямо хорошо сделать - тронешь где-то в одном месте, посыпется в другом. Надеюсь понятна моя мысль.
Интересно...
Есть ощущение, что в мире, в одночасье, будет разрушено очень большое количество сообществ, тем или иным способом базирующихся в Twitter. Кому Маск не по душе, а у кого возникнет стойкое ощущение, что город наступил на их дом, ну, как в фильме "Пустота" Винченцо Натали...
Соглашусь. Добавил. Хотя, когда писал этот пост, даже не думал о кликбейте.
Но, всё равно, спасибо за живую критику и обратную связь.
Согласен, в коллективной работе code style должен учитывать особенности кода продукта, разрабатываемого командой.
Но для личного code style оно вполне себе может работать.
Тут не поспоришь с Вами. Если бы была нужда - пошёл бы и купил и съездил и завёл и всё остальное.
Но чувство опустошения не покидает, всё равно.
Я вот так в чат организации написал, что вот - средние зарплаты. А меня шапками закидали, мол фигня, а не расчёт, мол один с зп в 2кк и остальные за 20ку. Показал, что - нет коллеги, вот медианы, вот перцентиль - не поверили.
Похоже многие сами не хотят об этом думать.
Никогда не думал с этой точки зрения. Да, человеческий фактор - суровая правда.
У нас, хоть и локальные репозитории, но никто не мешает косячить на проде с доступом извне.
Да, как начинаешь думать: чтобы себе сделать анонимную личность, нужно сим-карту левую (чтобы личность не твоя), телефон новый (чтобы текущий не спалить), поехать с ним и ноутом (желательно не твоим) в лес за 200 км (потому что вышки же и чтобы рядом телефона и быта твоего не было), а потом пользоваться только через vpn, да еще желательно в людных и разных местах, и т.д.т.п. Желание в этой личности пропадает.
Как в сериале "Полицейский с Рублёвки": "Да как они нас найдут?". "А фиг его знает, как мы их находим?"...
Я подозреваю, что автор имел ввиду, что если мы члены класса называем с префиксом my_, но при этом член класса - поле булевского типа (которые, по задумке автора стоит именовать с префиксами is_ или has_), то получается каша. Если принять во внимание Ваше предложение, получается, что для натуральности кода как языка - отлично, для понимания: что перед нами, переменная, поле класса, какого типа - неоднозначно.
Да, есть еще контекст, но тогда система его вроде не работает, получается))
За что я люблю Хабр и рад стать частью этого комьюнити. В комментариях, зачастую, можно найти огромное количество полезной информации и именно из-за Хабра я стал больше читать комментариев, под разными постами, на разных ресурсах.
Вам огромное спасибо за способ записи. С разбега сразу не гуглится. На Вашем примере отодвинул бы правые скобки к третьей строке, чтобы в глаза сразу бросился параметр функции. Простите за душность))
Согласен с Вами. Но я ни добавил, ни убавил. Ровно так, как написал автор статьи. Первое его предложение разрушает Ваши ожидания.
По поводу стилистики наименования элементов в разных языках — немного отдаёт самозатворничеством. Не считаю моветоном использование в своей программе стилистики, которая устраивает меня. Оговорюсь, что это не касается продуктов, которые разрабатываются командой, особенно там, где есть соглашение о коде. В своих работах пользуюсь подчёркиваниями в abl, в том числе (в Java пробовал - нормально выглядит). Хотя в abl чаще пользуются вообще, венгерской нотацией.
Как и большинство изучающих языки программирования, стараюсь читать документацию. Если в документации, создатели языка говорят о регистронезависимости операторов или ключевых слов - я пользуюсь этой информацией. Ну, скажем так, я не адепт больших букв в запросах к БД. Когда погружен в язык, нет необходимости выделять ключевые слова прописью, особенно с текущим уровнем различных редакторов и IDE. Да, есть огромное количество мест, где: не то, что цвета, вообще вёрстки толком нет — но и там, я знаю, большие буквы в select'е не становятся панацеей для удобства. Всё равно придётся прочитать всё, чтобы понять, что происходит, если код не твой. Если твой, то точно: большие буквы в тексте не ускорят процесс понимания и фиксации. Надеюсь, понят правильно.
Насчёт реформаторов - полностью с Вами согласен. Оригинального мало, но есть полезное. Я не защищаю, в данном случае Коэна Уиттерса, ну просто для себя нашёл некоторые полезные моменты, которые применил на практике.
Я думал, что первые комментарии будут как раз про ВерблюжьюТему и тему_с_подчёркиваниями :)
Было бы интересно посмотреть, кстати. pylint с 2004-го существует, статья 2009 года. Возможно тогда у них была какая-то синхронизация. Но, вопрос интересный.
Про операторы - это ко мне больше. Текст и так был большой, где-то его можно еще сократить, но не хотел отходить от оригинала. Я думаю, если поменять в этом тексте слово "оператор" на "ключевое слово", смысл не особо изменится.
В угоду лучшей видимости кода автор, всё же пренебрёг правилом "должно быть как естественный язык", тем более, что он поясняет это целостностью оператора (функции), в случае, если "прилепить" скобку к ключевому слову (имени функции).
Ну вот, например, из последнего:
Про организации - сто процентов, Ваша правда, но подкорректировать личный стиль кода никто не мешает. На скриншоте тоже видно, что у меня нет возможности быть "адептом стиля deWiTTERS", но что-то можно использовать. Вы же не используете стиль кода, которым писали в своей первой организации, во всех последующих?
А про изменение кода - это его профдеформация, как программиста. Я, например, часто не могу пройти мимо кода в продуктах своей организации, если там откровенный колхоз. Ну, правда, не всегда получается прямо хорошо сделать - тронешь где-то в одном месте, посыпется в другом. Надеюсь понятна моя мысль.