Комментарии 33
По соглашению имена классов объявляются с первой заглавной буквы и прописываются в верблюжьем регистре
Аж глазу больно стало. Это 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, а про ООП. Но я соглашусь с вами, что в век мозаичного мышления и копипасты кода из интернетов надо ответственнее относиться к своим примерам, особенно в "новичковых" статья, ибо каждая неверная буква отразится терабайтами мировой энтропии и триллионами багов и страданий людей :ॐ.
просто автор - бунтарь. Если в mdn сказано "не использовать стрелочные функции в качестве методов", то, значит, нужно делать наоборот
А мне статья понравилась.
Про проблемы с наследованием классно расписано, коротко и ясно. Но композиция это когда один класс содержит один или несколько других или по-другому, состоит из них. А вот функция, которая объекту присваивает поле-функцию, это только в JS, да и работает уже с созданными экземплярами
Про ООП на примере JS рассуждать - это странно, но самая дичь - это потуги про полиморфизм. Главная фишка полиморфизма - это возможность вызвать у переменной, имеющей тип родительского класса метод, переопределенный в наследниках, и наблюдать разный вариант в зависимости от того, какой наследник был инстанциирован и инстанс присвоен переменной типа родителя. То есть абстрагироваться от конкретной реализации в потомках
Мне, как начинающему, статья оказалось полезной. Написано интересно, без воды и с хорошими примерами. Для себя дополнительно почерпала инфу по классам javascript. Спасибо автору!
Знакомство с ООП на примере JavaScript