Pull to refresh

Comments 33

По соглашению имена классов объявляются с первой заглавной буквы и прописываются в верблюжьем регистре

Аж глазу больно стало. Это PascalCase называется.
Пардон, у автора в оригинале camelCase. Я считал, что вполне допустимо назвать его верблюжьим. Исправил на PascalCase.

PascalCase (античный термин) и CamelCase - синонимы, в JS также используется и lowerCamelCase, частный случай CamelCase.

Автор, уберите упоминание Паскаля, не втягивайте читателей в ретроградство :).

Спасибо, добрый человек. Снова исправил) Для себя на будущее запомнил.

https://ru.wikipedia.org/wiki/CamelCase

В языке Java принято использовать UpperCamelCase для именования классов и lowerCamelCase — для именования экземпляров классов и методов.

https://ru.wikipedia.org/wiki/Соглашения_об_именах_(программирование)#JavaScript

Встроенные библиотеки JavaScript используют те же соглашения об именах, что и Java.

https://skillbox.ru/media/code/notatsii-v-programmirovanii/

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

...

PascalCase - Тот же camelCase, но все слова, даже первое, начинаются с заглавной буквы.

...

Иногда Pascal case называют upper camel case или, наоборот, camel case называют low Pascal case.

IMHO - PascalCase это всегда PascalCase, а вот camelCase без (upper) и (lower) это х.з. что, по этому автор и уточняет регистр первой буквы. Изначально у вас все было правильно, "capital first letter and camelCase" и "с первой заглавной буквы и прописываются в верблюжьем регистре" - формально одно и то же, только общепринятый термин переводить не стоило.

"Прописываются" - это нотация, т.е. "По соглашению классы именуются в нотации camelCase с первой прописной буквой" (с первой буквой в верхнем регистре) или, что более понятно, "По соглашению классы именуются в нотации UpperCamelCase".

Снова исправлять ничего не надо, спасибо napa3um-у, уже все хорошо :)

Благодарю за доп. прояснение. Занятный у нас тут экскурс в тему регистров получился..:) Познавательный.

В комментариях была вскрыта новая фундаментальная проблема отрасли, почти что «табы против пробелов» :).

Опасную тему затрагиваете однако. Статью про "табы против" с Хабра неспроста убрали. Я так думаю :)

+1

В данном случае термины PascalCase и UpperCamelCase кажутся мне более подходящими, чем термин camelCase (да еще и с маленькой буквы), который только вводит в заблуждение. Невольно вспомнилась великолепная лекция Реймонда Хеттингера (Raymond Hettinger, один из разработчиков основных библиотек языка Python), в которой фигурировали слова RED, BLUE, GREEN и др., написанные неправильными цветами. :)

P.S. Cсылка с таймкодом на соответствующий момент в вышеупомянутой лекции:
https://youtu.be/wf-BqAjZb8M?t=41

Верблюжий регистр бывает и CamelCase, и camelCase, и указывает на «горбатое» написании слов. Да, величина первой буквы там обозначается графически :). Если же хочется различить и фонетически, то дополняют префиксом - lowerCamelCase или UpperCamelCase.

А Pascal[Case] - это древний артефакт, своими корнями уходящий в эпоху становления компиляторов, где обозначались не столько способы написания имён, сколько правила их преобразований при компиляции и бинарные форматы линковки (порядок заталкивания аргументов в стек, например).

Да и странным бы было писать, например, в одном и том же предложении: «Имена классов принято писать в PascalCase, а инстансы - в camelCase». Как говорится, или трусы, или крестик :). PascalCase не имеет симметричного lowerPascalCase (а если бы имел, то ваша аргументация потеряла бы смысл). Потому кэмел тут однозначно на коне :).

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

Вот, к примеру, "JavaScript Naming Conventions":
https://www.robinwieruch.de/javascript-naming-conventions/

ЦИТАТА:

A brief overview about the different case styles:
• camelCase (used in JS)
• PascalCase (used in JS)
• snake_case
• kebab-case

Как нетрудно заметить, аж четыре разных термина. Похоже, автор не видит в этом никаких проблем.

Еще статья, "JavaScript Style Guide":
https://www.w3schools.com/js/js_conventions.asp

ЦИТАТА:

PascalCase:

PascalCase is often preferred by C programmers.

camelCase:

camelCase is used by JavaScript itself, by jQuery, and other JavaScript libraries.

А вот термины UpperCamelCase и lowerCamelCase мне практически не попадаются. Возможно, не там ищу?

P.S. Запоздало нашел обсуждение "Clarify we mean UpperCamelCase, not lowerCamelCase by shepmaster · Pull Request #2389 · rust-lang/rfcs"
https://github.com/rust-lang/rfcs/pull/2389

Похоже, я таки был неправ касательно популярности термина PascalCase, извиняйте.

И тем не менее я предлагаю оставить Паскаля в покое, и использовать более удобную «симметричную» терминологию. Да, найти можно что угодно, я свой вариант аргументировал (и он тоже является широко расхожим, не лукавьте, будто не можете нагуглить) :).

Как нетрудно заметить, аж четыре разных термина. Похоже, автор не видит в этом никаких проблем.

Автор как раз пытается объять весь зоопарк терминов в этой статье. Мог и на мандаринском термины объяснить, для полноты. Но зачем же их все использовать в своей собственной статье не про стили написания слов? :)

https://en.m.wikipedia.org/wiki/Camel_case

P.S.: ?

Я ща может быть магию скажу, но ведь говорить и писать PascalCase и camelCase - гораздо удобнее, чем (впервые мною встреченные тут) варианты с upper/lower.

Говорить удобнее - потому что не требуются никакие уточнения, эти слова однозначно идентифицируют сущность

Писать - потому что короче. Писать camelCase надо именно с маленькой буквы, потому что, внезапно, по форме слова можно понять что имеется ввиду. Условно говоря, если на русском напишу: "используйте ВотТакойСтиль для классов, и вотТакойСтиль для переменных", - меня все сразу поймут, не задавая лишних вопросов.

Говорить удобнее так: "используй кэмэл-кейс, классы пиши с большой буквы, переменные - с маленькой". Т.е., уточнение говорится не птичьим языком, а естественным: "кэмэл-кейс с заглавной", "кэмэл-кейс с прописной". И все действительно сразу понимают.

Настоящие программисты собрались, как я погляжу: с десяток сообщений обсуждения как правильно назвать даже не поле, метод или класс, а сам стиль наименования, и при этом никто не обратил внимания на реальную ошибку в коде в статье ?

Автор, у тебя в самом первом блоке кода объект alien1 имеет метод phrase, а не sayPhrase, как все остальные, исправь, что ли :)

Наверное на это товарищу Germán Cocca надо указать. Автор тут только переводчик как я понял.

Germán Cocca
I'm a full stack dev (javascript | typescript | react | react native | node) and computer science student. Here I write about the things I learn along my path to becoming the best developer I can be.

Вот вам смешно, а мне плакать хочется.

Весь проект в одном стиле и один джун, не два Ждуна решили через нижние подчёркивание классы назвать. Уже3 год бесит, 300 леонидов из 350. Так что я за обсуждение как правильно делать и не портить нервную систему другим.

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

И вообще, JS не ООП как таковой, у него прототипная модель. В статье это где-то посередение и должным образом на это не обращают внимания.

Как я понял, JS тут лишь в качестве "псевдокода" для описания концептуальной модели ООП. Кстати, показан не совсем "настоящий ООП", а, скорее, "Си++ - ООП", ибо "настоящий", говорят, надо где-нибудь в Smalltalk / Objective C / Qt смотреть (или даже, сюрприз, в прототипном JS без "классового" сахара) :). Но мы рискуем нарваться на ещё один древнейший и фундаментальнейший холивар, по сравнению с которым табы с пробелами покажутся детской сказкой (и живые позавидуют мёртвым) :).

Основная претензия к стрелочным функциям. Если это статья для начинающих — то это только их запутает. Т.к. нужно сначала тогда обьяснить чем стрелочные отличаются от обычных, семантику this (а это одно из весьма замороченных мест в джаваскрипте)…

Я разработчик полного стека (javascript | typescript | react | react native | node) и студент факультета компьютерных наук. Здесь я пишу о том, чему я учусь на своем пути к тому, чтобы стать лучшим разработчиком, каким я могу быть.

Студент пишет о том, чему его учат. Все претензии к его преподавателям :)

Да и статья в оригинале называется "Object-Oriented Programming in JavaScript for Beginners"

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

Был как-то эпизод с олимпийским батутом (коим я занимался просто по фану) и рассказывал кому-то (тоже начинающему) про свои идеи и понимания процесса, и подошел опытный инструктор и сказал, что почти все что я рассказал — это неправильно и будет человеку активно мешать добится правильной формы при выполнении элемента… Было очень стыдно потом…

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

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

Несколько лет учил новичков в бут-кемпе. Синдром утенка представлен почти на 100% и плохие техники импринтятся на подкорку на раз, и потом сложно отучивать…

просто автор - бунтарь. Если в mdn сказано "не использовать стрелочные функции в качестве методов", то, значит, нужно делать наоборот

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

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

Мне, как начинающему, статья оказалось полезной. Написано интересно, без воды и с хорошими примерами. Для себя дополнительно почерпала инфу по классам javascript. Спасибо автору!

Sign up to leave a comment.