ЧтоВыДумаетеОПравилах НаименованииМетодовИПеременных?
НеНужноНедооцениватьЦенностьЧитабельностиКода
ПрограммистыНеДолжныНедооцениватьЦенностьЧитабельностиКода.СегодняМыПоговоримЕщеРазПроОбщиеПрактики,КоторыеВсеМы,Кажется, ПринимаемЗаДолжное: НаименованиеПеременныхИМетодов.
ВродеТакаяНезначительнаяНаПервыйВзглядВещь,Верно?КакойКейсОбычноИспользуютПрограммистыЧтобыСвязатьСлова:Верблюжий,ЗмеиныйИлиШашлычный(Кебаб), ИВообще, ТакЛиЭтоВажно?
ЧитаемостьюКодаНеСледуетПренебрегать.ЭтоВлияет,КакЛегкоВыМожетеПеремещатьсяИПониматьСвойИлиЧужойКод.
ИтакЯзыкиРаннегоПрограммированияНеИмелиТехЖеСоглашений,КоторыеМыИмеемСегодня.ТакиеЯзыки,КакLispИCOBOL,ПоявилисьДоШирокойПоддержкиASCII. ПрописныеИСтрочныеБуквы,АТакжеСпециальныеСимволы,ТакиеКакПодчеркивание,ПростоНеПподдерживалисьКомпиляторамиЕщеВНачале50-хИ60-хГодов.
ИЛиспИКоболПозволяютДефисамРазделятьСлова.АнализаторLispБылДостаточноУмен,ЧтобыОпределить,БылЛиДефисМеждуДвумяСловами, ИлиЕгоСледуетИспользоватьВКачествеОператораВычитания.ВCOBOLВКачествеОператоровИспользуютсяТолькоПолныеСлова,ИНеИмеетЭтуПроблему. ВотПримерВычитанияВКоболе:
SUBTRACT data-item-1 FROM data-item-2ПосколькуДефисНеЯвляетсяЗарезервированнымКлючевымСловом,ЕгоМожноИспользоватьДляРазделенияСлов.
КогдаЯзыкиПрограммированияСозрелиВ80-хИ90-хГгодах,СталоЯсно,ЧтоДефисДолженБытьЗарезервированДляМатематическихОпераций.ЕщеОднаПроблемаСУмнымодходомLispЗаключаласьВТом,ЧтоОнНеМасштабировалсяВСовременныхЯзыкахИЗначительноЗамедлялТокенизацию.
Пробелы,Очевидно,НикогдаНеМогутБытьИспользованы,ТакКакПочтиКаждыйЯзыкПрограммированияИспользуетИхВКачествеГраницМеждуТокенами.ТакЧтоЖеОстается?КакМыМожемНаписатьНесколькоСловКакОдно,СохраняяЧитаемостьЭтихСлов?
ИМыПодошлиКТомуПочемуСегодняМыОсталисьСДвумяОсновнымиСсоглашениями:CamelCase,ЛибоСоСтрочнойБуквыЛибоСЗаглавнойИSnakeCase.КстатиЗаглавныйРегистрCamelCaseТакжеНазываетсяPascalCase.
ПоБольшейЧастиВКаждомЯзыкеИмеетМестоБытьОдинИзЭтихВариантов.МожноСказатьЧтоЭтоПростоВопросПринциповСообществ(ПриветПайтонистам),ИПокончитьСЭтим.
НоПоднимаяТемуЧитабельностиКодаНеСложноЗаметитьЧтоCamelCaseДелаетТекстБолееТруднымДляЧтенияПоСравнениюСSnakeCase.
ЕслиСравнитьДваНижеСледующихВариантаНаписанияПеременной:
userId
user_idВашМозгУжеПодсказываетВамЧтоЕмуЛегчеПрочесть,Верно? :)
ИЭтоДействительноТак:CamelCaseБолееКомпактен:ВамНеНужноПисатьБольше.НоЭтоНеТотСтильКоторыйБлижеВсегоКТому,КакЧеловеческийМозгНаСамомДелеЧитаетТекст.
ЭтоСущественныйАргумент,КоторыйИмеетЗначениеВДискуссии:КакСделатьТакЧтобыНашемуМозгуБылоКакМожноПрощеЧитатьИПониматьКод.
ЧитаемыйКодСнижаетКогнитивнуюНагрузку.МеньшаяКогнитивнаяНагрузкаОзначаетБольшеПамятиДляЛюдейЧтобыДуматьОДругихВещах,ТакихКакНаписаниеБизнесЛогики.
"ИВесьПостТолькоОПользеПодчеркивания?" КонечноНет,НеТолькоИз-заЭтого. НаписаниеЧитаемогоКодаНамногоБольше, ЧемСоглашенияОбИименовании. НоТакиеМелочиПомогаютПолучитьБолееЛучшееРешение.
Aleksandr02.11.2023
Вы пишите о пользе SnakeCase для чтения, но сами при этом используете CamelCase в своих листингах. Почему именно такой выбор?
Хороший вопрос)
Стандарты PSR, а затем далее популярные фреймворки по сути задали вектор направления.
Как в посте сказано у всего есть свои плюсы и минусы, будь то camelCase, snake_case, ну и тот же PascalCase.
И конечной точкой в наименовании переменных, конечно же, является регламент внутри команды, вы можете идти даже против стандартов, если всех ваших разработчиков все устраивает)