Здравствуйте, MadHuman, Вы писали: MH>Если б у вас был выбор что выбрать, или если сложилось впечатление о преимуществах одной перед другой, или то что напрягает, welcome поделиться ...
Мне пофиг. Меня напрягло это только один раз: команда полгода вырабатывала общий нейминг, таки родила документ, босс приказал всем писать строго по нему и через месяц спросил в каком лесу меня научили начинать имена приватных членов с подчеркивания? Я, конечно, указал номер страницы, босс мне, конечно, ответил "бл...", но с тех пор я окончательно уверился что всем пофиг и по примеру босса прекратил читать всякую чушь.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, MadHuman, Вы писали:
MH> MH>> а как у вас?... MH> DC>Я всегда использую Camel Case. На любом языке. Мне так удобно. MH> А какие у вас вызывает эмоции использование Camel Case например в js? особенно если используются и сторонние библиотеки с lowerCamelCase ?
Есть разные naming convention. В разные времена довелось поработать с разными технологиями имеющие разные конвенции (C#, javascript, sql, html, css итп). Если к какой-то привыкнуть, то вообщем нормально, но когда переключаешся между средами с разными конвенциями, то несколько подняпрягает... и непонятны преимущества их друг перед другом.
Если б у вас был выбор что выбрать, или если сложилось впечатление о преимуществах одной перед другой, или то что напрягает, welcome поделиться ...
например меня напрягает, разница между C# и javascript — в C# имена методов/полей класса с большой буквы, а в js — имена с маленькой.
но нет ощущения что какая-то лучше).
также в sql удобно что функции и поля в таблицах именуются с маленьких букв, но когда в проекте смешиаваются что-то типа EF и ручного sql, то опять же разница в конвенциях режет глаз.
Здравствуйте, MadHuman, Вы писали:
MH>также в sql удобно что функции и поля в таблицах именуются с маленьких букв, но когда в проекте смешиаваются что-то типа EF и ручного sql, то опять же разница в конвенциях режет глаз.
<offtopic>
Возьмите LINQ2DB и перестаньте писать ручной SQL
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, MadHuman, Вы писали:
MH>>также в sql удобно что функции и поля в таблицах именуются с маленьких букв, но когда в проекте смешиваются что-то типа EF и ручного sql, то опять же разница в конвенциях режет глаз. _NN><offtopic> _NN>Возьмите LINQ2DB и перестаньте писать ручной SQL
Спасибо, про linq , linq2db я в курсе и это несколько не то что хотелось бы обсудить
Здравствуйте, MadHuman, Вы писали: MH>Есть разные naming convention. В разные времена довелось поработать с разными технологиями имеющие разные конвенции (C#, javascript, sql, html, css итп). Если к какой-то привыкнуть, то вообщем нормально, но когда переключаешся между средами с разными конвенциями, то несколько подняпрягает... и непонятны преимущества их друг перед другом.
Это уже обсуждали.
Единственное требование — consistency. Напрягает именно смешение конвенций.
Поэтому если работаете с платформой, то применяйте конвенцию, принятую на этой платформе по дефолту. Иначе будете всю жизь мучиться, глядя на Pascal конвенцию в Java коде, где все остальыне используют кэмел.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Единственное требование — consistency. Напрягает именно смешение конвенций.
так
S>Поэтому если работаете с платформой, то применяйте конвенцию, принятую на этой платформе по дефолту.
дак вот тут и проблема. если C# и javascript (как часть asp.net mvc проекта), конвенции разные, и это и напрягает — переключение туда/сюда.
Здравствуйте, DenisCh, Вы писали:
MH>> а как у вас?...
DC>Я всегда использую Camel Case. На любом языке. Мне так удобно.
А какие у вас вызывает эмоции использование Camel Case например в js? особенно если используются и сторонние библиотеки с lowerCamelCase ?
Здравствуйте, MadHuman, Вы писали:
MH>А какие у вас вызывает эмоции использование Camel Case например в js? особенно если используются и сторонние библиотеки с lowerCamelCase ?
Почему это вообще должно вызывать какие-то особые эмоции?
Мой идеальный naming convention это нормальные слова с пробелами. Но поддержку такого я видел только в SQL и, как ни странно, в BAT-файлах. Вроде теоретически в Kotlin можно, если каждый идентификатор обрамлять обратными кавычками, не пробовал писать в таком стиле. Видимо пробел это слишком ценный символ, чтобы отдавать его идентификаторам. Второй по идеальности это полностью lower-case с подчёркиваниями. Такой видел только в C. Почему верблюды самые популярные, я вообще не понимаю. Может быть это влияние английской традиции типографики, для меня дико выглядит разделение слов большими буквами, хотя и приходится прогибаться под изменчивый мир. Но будь моя воля, я бы писал именно_так.
Здравствуйте, Евгений Музыченко, Вы писали:
MH>>А какие у вас вызывает эмоции использование Camel Case например в js? особенно если используются и сторонние библиотеки с lowerCamelCase ?
ЕМ>Почему это вообще должно вызывать какие-то особые эмоции?
ломка привычки обычно не вызывает приятных эмоций хотя в данном случае "ломка" слишком громко, но всё равно отступление от привычного.
например, у меня — пописав на lowerCamelCase и затем переключившись на C# (Camel Case), некоторое время часто возникает желание (причем довольно сильное) продолжать использовать lowerCamelCase , но коллеги потом бывают недовольны
Здравствуйте, MadHuman, Вы писали:
MH>например, у меня — попИсав на lowerCamelCase и затем переключившись на C# (Camel Case), некоторое время часто возникает желание (причем довольно сильное) продолжать использовать lowerCamelCase , но коллеги потом бывают недовольны
При коллективной разработке нужно принять единый стиль, и придерживаться его всем. При индивидуальной можно использовать любой.
Здравствуйте, vsb, Вы писали:
vsb>Мой идеальный naming convention это нормальные слова с пробелами. Но поддержку такого я видел только в SQL и, как ни странно, в BAT-файлах. Вроде теоретически в Kotlin можно, если каждый идентификатор обрамлять обратными кавычками, не пробовал писать в таком стиле.
Знаю один локальный язычек, где такое можно, и там прижилось только для записи имен переменных являющихся одновременно полями БД. vsb>Видимо пробел это слишком ценный символ, чтобы отдавать его идентификаторам.
Кавычки мешают читать. И большая длина идентификаторов не способствует легкому восприятию.
vsb> Второй по идеальности это полностью lower-case с подчёркиваниями. Такой видел только в C. Почему верблюды самые популярные, я вообще не понимаю. Может быть это влияние английской традиции типографики, для меня дико выглядит разделение слов большими буквами, хотя и приходится прогибаться под изменчивый мир. Но будь моя воля, я бы писал именно_так.
А меня подчеркивания в качестве пробелов раздражают и мешают читать CamelCase или lowerCamelCase читается гораздо легче. Дело привычки.
Здравствуйте, vsb, Вы писали:
vsb>Мой идеальный naming convention это нормальные слова с пробелами. Но поддержку такого я видел только в SQL и, как ни странно, в BAT-файлах
В большинстве ЯП идентификатор — это термин, используемый в рамках утверждения (оператора). Если делать ЯП, приближенный к естественному языку, то и элементы утверждения логично разделять именно пробелом. Во всех науках и технологиях всегда старались использовать однословные термины, чтобы не возникало разночтений при изменении падежей, использовании управляющих/управляемых конструкций и т.п.
Кстати, в BAT/CMD пробелы допустимы только в именах переменных, которые ограничиваются спецсимволами. В именах меток, по понятной причине, их использовать не получится.
vsb>Видимо пробел это слишком ценный символ, чтобы отдавать его идентификаторам.
Он не то, чтобы ценный, он просто традиционный (и естественный) разделитель.
vsb>Почему верблюды самые популярные, я вообще не понимаю.
Они достигают сразу двух целей — разделяют слова и экономят пространство на разделителях. Проблемы возникают исключительно на аббревиатурах, которые принято записывать заглавными буквами.
Здравствуйте, pagid, Вы писали:
vsb>>Видимо пробел это слишком ценный символ, чтобы отдавать его идентификаторам. P>Кавычки мешают читать.
IDE это может улучшить. Например скрыть кавычки (или сделать их блёклыми) и выделить идентификатор прямоугольником, чтобы подчеркнуть его логически-единую сущность.
P>И большая длина идентификаторов не способствует легкому восприятию.
Почему это? Посмотри на Java, там полно длинных идентификаторов. Мне наоборот всяческие сокращения мешают лёгкому восприятию (кроме общепринятых). Хотя, конечно, есть и культура юникса с его strncpy, хз.
vsb>> Второй по идеальности это полностью lower-case с подчёркиваниями. Такой видел только в C. Почему верблюды самые популярные, я вообще не понимаю. Может быть это влияние английской традиции типографики, для меня дико выглядит разделение слов большими буквами, хотя и приходится прогибаться под изменчивый мир. Но будь моя воля, я бы писал именно_так. P>А меня подчеркивания в качестве пробелов раздражают и мешают читать CamelCase или lowerCamelCase читается гораздо легче. Дело привычки.
Ну у меня точно не дело привычки, т.к. я всю жизнь пишу на Java.
Здравствуйте, Евгений Музыченко, Вы писали:
vsb>>Мой идеальный naming convention это нормальные слова с пробелами. Но поддержку такого я видел только в SQL и, как ни странно, в BAT-файлах
ЕМ>В большинстве ЯП идентификатор — это термин, используемый в рамках утверждения (оператора). Если делать ЯП, приближенный к естественному языку, то и элементы утверждения логично разделять именно пробелом. Во всех науках и технологиях всегда старались использовать однословные термины, чтобы не возникало разночтений при изменении падежей, использовании управляющих/управляемых конструкций и т.п.
Но элементы утверждения в ЯП разделяются не пробелами, а операторами. Пробел как значащий символ я помню только в хаскеле (ну видимо и в других похожих функциональных языках). По-мне текст вида
let person name = person.get name
if (person name.starts with("a")) {
person.set name("b")
}
читается нормально. Хотя в идеале нужна подсветка IDE.
ЕМ>Кстати, в BAT/CMD пробелы допустимы только в именах переменных, которые ограничиваются спецсимволами. В именах меток, по понятной причине, их использовать не получится.
Да, можно было бы и получше спроектировать, скажем ограничивать метку двоеточиями. Ну да ладно, кто там на этих bat-никах чего пишет, скорее так, курьёзный факт.
vsb>>Почему верблюды самые популярные, я вообще не понимаю.
ЕМ>Они достигают сразу двух целей — разделяют слова и экономят пространство на разделителях.
Чего там это пространство экономить в 21-м веке. Хоть 55-дюймовые мониторы покупай. Хотя мне и 27 хватает на 140 символов в ширину, что позволяет обходиться почти без переносов.
Здравствуйте, vsb, Вы писали:
vsb>IDE это может улучшить. Например скрыть кавычки (или сделать их блёклыми) и выделить идентификатор прямоугольником, чтобы подчеркнуть его логически-единую сущность.
В том частном случае она умееет выделять подобный идентификатор цветом, несиотря на свою примитивность, в этом случае даже кавычки не так мешают, но все равно не прижилось. А вот выделять в тексте программы что-то кроме ошибок не цветом букв, а цветом фона — прямоугольником, это совершенно дурной способ.
vsb>Почему это? Посмотри на Java, там полно длинных идентификаторов. Мне наоборот всяческие сокращения мешают лёгкому восприятию (кроме общепринятых). Хотя, конечно, есть и культура юникса с его strncpy, хз.
То и другое в топку. Но это конечно не призыв скрестить мечи обсуждая эту проблему. Хотя если strncpy в конкретной программе часто используемая функция, ну вместе с остальными strstr, то вариант нормальный.
Здравствуйте, pagid, Вы писали:
vsb>>IDE это может улучшить. Например скрыть кавычки (или сделать их блёклыми) и выделить идентификатор прямоугольником, чтобы подчеркнуть его логически-единую сущность. P>В том частном случае она умееет выделять подобный идентификатор цветом, несиотря на свою примитивность, в этом случае даже кавычки не так мешают, но все равно не прижилось. А вот выделять в тексте программы что-то кроме ошибок не цветом букв, а цветом фона — прямоугольником, это совершенно дурной способ.
Ну у меня Idea выделяет и мне это очень нравится. Пожалуй это одно из немногих улучшений текста, которые я не отключаю.
vsb>>Почему это? Посмотри на Java, там полно длинных идентификаторов. Мне наоборот всяческие сокращения мешают лёгкому восприятию (кроме общепринятых). Хотя, конечно, есть и культура юникса с его strncpy, хз. P>То и другое в топку. Но это конечно не призыв скрестить мечи обсуждая эту проблему. Хотя если strncpy в конкретной программе часто используемая функция, ну вместе с остальными strstr, то вариант нормальный.
Хз, я использую многословные идентификаторы и мне это нравится. Если длина меньше 30 символов, проблем вообще нет. Если больше — смотря как часто используется.
Здравствуйте, vsb, Вы писали:
vsb>Но элементы утверждения в ЯП разделяются не пробелами, а операторами.
Вы хотели сказать "операциями" (operator)? Утверждение — это оператор (statement).
По-мне текст вида vsb>
vsb>let person name = person.get name
vsb>if (person name.starts with("a")) {
vsb> person.set name("b")
vsb>}
vsb>
vsb>читается нормально. Хотя в идеале нужна подсветка IDE.
С подсветкой он еще худо-бедно читается, а без подсветки — только после предварительной настройки мозга. Если пробел может быть частью идентификатора, то "let person name" — идентификатор, а не ключевое слово "let", за которым следует идентификатор "person name". Мозг, привыкший читать тексты на естественных языках, автоматически делит "person name.starts with" на "person", "name.starts" и "with" (точка, за которой не следует пробела, не воспринимается, как конец предложения).
vsb>Да, можно было бы и получше спроектировать, скажем ограничивать метку двоеточиями.
Тогда уж ввести какой-нибудь универсальный ограничитель, вроде обратных кавычек.
vsb>Ну да ладно, кто там на этих bat-никах чего пишет, скорее так, курьёзный факт.
В них еще и синтаксиса единого никогда не было, вот случайно и получилось.
vsb>>>Почему верблюды самые популярные, я вообще не понимаю.
vsb>Чего там это пространство экономить в 21-м веке.
В 21-м веке у людей выросли дополнительные пальцы для набора дополнительных символов?
vsb>Хоть 55-дюймовые мониторы покупай.
И вози их с собой, ввиду возрастающей мобильности? Ну и банально неудобно вертеть головой там, где в иных условиях достаточно движения глаз.
vsb>Хотя мне и 27 хватает на 140 символов в ширину, что позволяет обходиться почти без переносов.
Это на любителя. Большинству некомфортны длинные строки, за ними труднее следить глазами. "Портретный" формат книг устоялся не просто так.
Здравствуйте, MadHuman, Вы писали:
MH>Если б у вас был выбор что выбрать, или если сложилось впечатление о преимуществах одной перед другой, или то что напрягает, welcome поделиться ...
Объективно наиболее правильная конвенция в Java. Она позволяет сразу отличать имена методов (camelCase) от классов (CamelCase) и более компактна, чем имена_с_подёркиваниями.
Здравствуйте, MadHuman, Вы писали:
MH>Приветствую, коллеги.
MH>Есть разные naming convention. В разные времена довелось поработать с разными технологиями имеющие разные конвенции (C#, javascript, sql, html, css итп). Если к какой-то привыкнуть, то вообщем нормально, но когда переключаешся между средами с разными конвенциями, то несколько подняпрягает... и непонятны преимущества их друг перед другом.
Меня больше напрягает отсутствие единого стиля или документации к нему в команде. Если все неукоснительно придерживаются единого стиля, то код выглядит хорошо, даже если стиль какой-то вычурный. Вообще, предпочитаю, чтобы стиль был таким же как в базовых библиотеках (рантайме) используемого языка.
Я, конечно, указал номер страницы, босс мне, конечно, ответил "бл...", но с тех пор я окончательно уверился что всем пофиг и по примеру босса прекратил читать всякую чушь.
CamelCase или lowerCamelCase читается гораздо легче. Дело привычки.
