Здравствуйте, Аноним, Вы писали:
А>Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
Ничего не изменилось. Никто никогда не рекомендовал именовать приватные методы с маленькой буквы. С маленькой буквы именуются только локальные функции в Немерле.
Если нам не помогут, то мы тоже никого не пощадим.
Сейчас почему то мода пошла и приватные и публичные писать с большой. Но ведь это не удобно -- по названию метода должно быть стразу понятно публичный он или приватный. Разница огромная. Как минимум, в приватных нет проверки аргументов на null, а в публичных есть. Публичность/приватность должна бросаться в глаза.
Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
Re: Приватные методы с маленькой, публичные с большой
Здравствуйте, Аноним, Вы писали:
А>Сейчас почему то мода пошла и приватные и публичные писать с большой. Но ведь это не удобно -- по названию метода должно быть стразу понятно публичный он или приватный. Разница огромная. Как минимум, в приватных нет проверки аргументов на null, а в публичных есть. Публичность/приватность должна бросаться в глаза.
А>Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
Первый раз слышу про приватные методы с маленькой буквы
Re[2]: Приватные методы с маленькой, публичные с большой
Здравствуйте, _NN_, Вы писали:
_NN>Сегодня метод приватный, а завтра его делаем публичным и везде меняй регистр.
Не только менять регистр, но и добавлять проверку входных параметров. Вообще это серьезное изменение архитектуры, так что буква далеко не самый главный момент в этом случае. Буква меняется одним нажатием кнопки, а вот остальное не так просто.
_NN>А вот "protected" это приватный или публичный ? Аналогично с internal. _NN>Как тут поступать ?
Критерий очень простой: там, где вы проверяете аргументы метода на null -- пишем с большой буквы, где нет -- с маленькой. То есть там, где маленькая буква, передаются 100% валидные аргументы (потому что вызываем его только мы для внутренних нужд и никто другой туда каку передать не сможет).
То есть protected с большой, т.к. могут передать неверные аргументы из стороннего кода. Internal -- я тоже пишу с большой, т.к. сам случайно могу передать туда не то что нужно (всего в голове не удержишь).
Итого, с маленькой только чистый private.
Re[10]: Приватные методы с маленькой, публичные с большой
Здравствуйте, _Raz_, Вы писали:
_R_>При чем тут библиотеки? Это соглашения по написанию кода, но принимаются они для легкого чтения. Вот вы привыкли читать с маленькой буквы и ввели свой code style — но эта привычка далека от си шарпа. Более того — она вредна. Упрощая себе code review вы усложняете жизнь пишущим в правильном стиле, заставляя задумываться о том как пишешь, а не что пишешь и какой ... ввел это в корпоративный стандарт.
Корпоративный стандарт, батенька, может быть глупой выдумкой. А может быть и постарше нас с Вами, и тогда отступление от общепринятого может иметь очень давние корни десятилетий и высокую цену отказа от. Поэтому постепенно лично я пришел к правилу, что садясь за новый проект или инструмент, лучше не лезть туда со своим уставом, а переконфигурировать собственный мозг. А то до смешного доходит, когда народ даже раскладку клавиатуры под себя лепит, не говоря уже про набор шорткатов в IDE. Типа, так привык, и по-другому уже не умею.
Лёгкость вообще — понятие субъективное, равно как и "правильность". Иначе ведь можно было бы закрепить один "правильный лёгкий" способ на уровне синтаксиса языка и не париться.
Помнится, первый раз попробовал написать в студенчестве прогу на Сях (после освоения Паскаля). Написал код красиво, чтобы читать было "легко и правильно", все идентификаторы сделал с заглавной буквы... В том числе и функцию main() назвал Main() — а оно не компилит...
Re: Приватные методы с маленькой, публичные с большой
Здравствуйте, Аноним, Вы писали:
А>Сейчас почему то мода пошла и приватные и публичные писать с большой. Но ведь это не удобно -- по названию метода должно быть стразу понятно публичный он или приватный. Разница огромная. Как минимум, в приватных нет проверки аргументов на null, а в публичных есть. Публичность/приватность должна бросаться в глаза.
А>Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
У нас такое используется.
Но мне больше не нравится чем нравится.
Сегодня метод приватный, а завтра его делаем публичным и везде меняй регистр.
А вот "protected" это приватный или публичный ? Аналогично с internal.
Как тут поступать ?
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, _NN_, Вы писали: _NN>>А вот "protected" это приватный или публичный ? Аналогично с internal.
QL>К публичным относятся public, protected и protected internal.
Ну вот, а некоторые считают, что protected относится как раз к приватным.
Тут как бы вопрос что есть публичное, что приватное.
Если смотреть относительно класса, то public и internal.
А если смотреть относительно сборки, то тогда ваш вариант.
QL>К приватным — private и internal.
Здравствуйте, _NN_, Вы писали: _NN>Ну вот, а некоторые считают, что protected относится как раз к приватным.
Они ошибаются =)
Приватные — видимые только внутри контейнера (класса/сборки) — private/internal. Все остальные — публичные.
Re[4]: Приватные методы с маленькой, публичные с большой
Здравствуйте, _NN_, Вы писали:
QL>>К публичным относятся public, protected и protected internal.
_NN>Ну вот, а некоторые считают, что protected относится как раз к приватным. _NN>Тут как бы вопрос что есть публичное, что приватное.
В protected могут передать неверные аргументы, по этому производим их проверку. А следовательно, и писать нужно с большой буквы.
_NN>Если смотреть относительно класса, то public и internal. _NN>А если смотреть относительно сборки, то тогда ваш вариант.
Нужно смотреть относительно необходимости проверки аргументов на null.
Re[5]: Приватные методы с маленькой, публичные с большой
Здравствуйте, _NN_, Вы писали:
_NN>Мое личное мнение, всегда писать с большой буквы и не париться
А приватные поля, локальные переменные, аргументы методов вы тоже с большой пишите? Почему же с этим паритесь??? Пишите как в Delphi -- все с большой буквы.
Почему приватные поля пишите с маленькой, а приватные методы с большой? Где критерий?
Re[7]: Приватные методы с маленькой, публичные с большой
Приватные вообще не обязаны регламентироваться стандартом, т.к. это не влияет на использование библиотеки.
_R_>Да-же проще, чем не выплатить заработанное.
Не понятно с какой целью вы здесь это пишите? Во-первых, вопросы оплаты я не решаю. Во-вторых, не всегда заказчик не прав. Работнички ведь тоже разные бывают. Могу сказать, что кроме вас проблемы по оплате ни с кем более не возникали.
Re[3]: Приватные методы с маленькой, публичные с большой
По-моему эта мода пошла от исходников Microsort
Если Reflector'ом посмотреть их исходники, там все методы и приватные и публичные с заглавной буквы.
Зато там встречаются пары методов: публичный X и приватный XInternal.
Я придерживаюсь правила: приватные методы с маленькой буквы. У бывают пары: публичный X и приватный x. MS'подход мне не нравится, так как увеличивает длину названия метода.
Здравствуйте, IObserver, Вы писали:
IO>В табличке написано:
IO>Property IO>Pascal IO>BackColor
IO>без всяких уточнений (приватные или публичные).
А кто сказал, что уточнения должны быть. Ясно же сказано, что метод — с заглавной буквы.
IO>Приватные вообще не обязаны регламентироваться стандартом,
Обязаны.
IO>т.к. это не влияет на использование библиотеки.
При чем тут библиотеки? Это соглашения по написанию кода, но принимаются они для легкого чтения. Вот вы привыкли читать с маленькой буквы и ввели свой code style — но эта привычка далека от си шарпа. Более того — она вредна. Упрощая себе code review вы усложняете жизнь пишущим в правильном стиле, заставляя задумываться о том как пишешь, а не что пишешь и какой ... ввел это в корпоративный стандарт.
И доводы типа
В protected могут передать неверные аргументы, по этому производим их проверку. А следовательно, и писать нужно с большой буквы.
и
Нужно смотреть относительно необходимости проверки аргументов на null.
не могут служить оправданием для отступа от общепринятых соглашений code style-а. Нет таких позиций относительно шарпа. Тут нет венгерской нотации и нет методов со строчной буквы. Плохо это или хорошо, нравиться тебе или нет, но это общепринятое соглашение. Есть code style — его нужно соблюдать. Точка. Только вот он должен быть не придуман кем-то в команде и не натаскан кусками из других языков программирования. Даже если 100% команды привыкли к стилю иного языка. Завтра придет новый разработчик и время на чтение существующего кода будет значительно выше, по сравнению с кодом написанным по правилам.
... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 32>>
Re[4]: Приватные методы с маленькой, публичные с большой
Здравствуйте, igor-booch, Вы писали:
IB>По-моему эта мода пошла от исходников Microsort IB>Если Reflector'ом посмотреть их исходники, там все методы и приватные и публичные с заглавной буквы.
Эта мода пошла за долго до рефлектора и .net. В плюсах для приватных методов точно такое соглашение.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Приватные методы с маленькой, публичные с большой
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, _NN_, Вы писали: _NN>>А вот "protected" это приватный или публичный ? Аналогично с internal.
QL>К публичным относятся public, protected и protected internal. QL>К приватным — private и internal.
Если уж делить область видимость членов на две категории, то не на (1) открытые и (2) закрытые, а тогда уж на (1) закрытые и (2) exposable. Т.е. все, что не приватное, то exposable, т.е. доступно кому-то вне этого класса. При этом у этого множества "досутпных не только мне" членов есть подмножества: открытые методы, закрытые, внутренние. В том же Eiffel-е класс может экспоузить свои члены конкретным классам, это не делает эти члены публичными.
Но в любом случае, различные идиомы именования методов в зависимости от области видимости — не приняты. Вот поля — другое дело. Сокласно Framework Design Guidelines открытые поля в PascalCase-е, а вот закрытые поля — в camelCase-е с возможность использования лидирующего подчеркивания.
Re[11]: Приватные методы с маленькой, публичные с большой
Здравствуйте, Mr.Delphist, Вы писали:
MD>Корпоративный стандарт, батенька, может быть глупой выдумкой. А может быть и постарше нас с Вами, и тогда отступление от общепринятого может иметь очень давние корни десятилетий и высокую цену отказа от. Поэтому постепенно лично я пришел к правилу, что садясь за новый проект или инструмент, лучше не лезть туда со своим уставом, а переконфигурировать собственный мозг. А то до смешного доходит, когда народ даже раскладку клавиатуры под себя лепит, не говоря уже про набор шорткатов в IDE. Типа, так привык, и по-другому уже не умею.
MD>Лёгкость вообще — понятие субъективное, равно как и "правильность". Иначе ведь можно было бы закрепить один "правильный лёгкий" способ на уровне синтаксиса языка и не париться. MD>Помнится, первый раз попробовал написать в студенчестве прогу на Сях (после освоения Паскаля). Написал код красиво, чтобы читать было "легко и правильно", все идентификаторы сделал с заглавной буквы... В том числе и функцию main() назвал Main() — а оно не компилит...
Об этом и речь. Только вот не все доходят до правила переконфигурирования мозга, пусть даже и постепенно. Что печально.
... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 32>>
Re: Приватные методы с маленькой, публичные с большой
Я немного не пойму, почему многие отписавшиеся так упорно настаивают, что положено все методы писать с прописной буквы. Мол, это стандарт и гайдлайн. Но ведь сама студия генерирует методы-обработчики событий с маленькой буквы. Кидаем на ВинФорму кнопочку (например, имя у неё buttonOk), дабл-клик — создаётся метод buttonOk_Click. Как видим, с маленькой буквы. Насильно менять его на PascalCase? Что в этом случае делать?
Re[2]: Приватные методы с маленькой, публичные с большой
Здравствуйте, koodeer, Вы писали:
K>Но ведь сама студия генерирует методы-обработчики событий с маленькой буквы
Это сниппет, который "пляшет" от имени источника событий, поэтому для холивара пример не годится.
Вообще, как в команде принято, так и пишем. Если в команде принято так, как в гайдлайнах — хорошо, новому разработчику будет легче. Если нет — плохо, но а что делать, не переписывать же из-за одного человека кучу кода.
Re[4]: Приватные методы с маленькой, публичные с большой
От:
Аноним
Дата:
23.01.12 18:09
Оценка:
Здравствуйте, _NN_, Вы писали:
_NN>>>У нас такое используется. А>>В программах на C#? _NN>Да.
И что вас привело к использованию такой нотации, откуда это вообще взялось?
Re[5]: Приватные методы с маленькой, публичные с большой
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _NN_, Вы писали:
_NN>>>>У нас такое используется. А>>>В программах на C#? _NN>>Да.
А>И что вас привело к использованию такой нотации, откуда это вообще взялось?
Такой стандарт на кодирование.
Так что вопрос не ко мне.
Здравствуйте, Аноним, Вы писали:
А>Как минимум, в приватных нет проверки аргументов на null, а в публичных есть.
Очень сомнительное правило. А если я делегат на приватный метод передаю наружу (например, подписваясь на событие), то что, тоже не нужно делать проверки аргументов? Или обязательно должно сделать метод публичным?
Re[2]: Приватные методы с маленькой, публичные с большой
Здравствуйте, Visor2004, Вы писали:
V>Это вот с какой радости в приватных методах нет проверок?
Вопрос проверок аргументов на null сам по себе довольно спорный. Некоторые считают это пустой тратой времени (см. предыдущие обсуждения), т.к. ANE сейчас, по их мнению, ничем не лучше NRE потом.
Большинство соглашаются с тем, что в приватные методы передаются более менее достоверные данные (они как бы продолжением публичного метода, где все данные уже проверены). По этому проверки либо не используются вообще, либо используются Debug.Assert.
Re: Приватные методы с маленькой, публичные с большой
Здравствуйте, Аноним, Вы писали:
А>Сейчас почему то мода пошла и приватные и публичные писать с большой. Но ведь это не удобно -- по названию метода должно быть стразу понятно публичный он или приватный. Разница огромная. Как минимум, в приватных нет проверки аргументов на null, а в публичных есть. Публичность/приватность должна бросаться в глаза. А>Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
Я с Net-ом не работаю, но позволю себе вставить здесь свои 5 копеек:
— посмотрите на язык Go: там точно так — с больших букв начинаются публичные элементы, и это синтаксис языка. Но там нет ни public, ни privat и прочего словестного шума;
— посмотрите код на Эрланге: там с большой буквы начинаются переменные, всё остальное — с маленькой. Это синтаксис языка, всё легко воспринимается без всяких "var" и пр.;
— в Хаскеле: всё, что касается типов — с большой, функции и переменные — с маленькой. Вся публичность описывается в начале модуля со всей документацией (комментариями), дальше — занимайся реализацией, думая конкретно о функционале, без заморочек — "privat"-ить здесь или "protected"-ить. В целом — образцовая стройность языка, и это его синтаксис;
— сугубо мой личный вкус: код с CamelCase или PascalCase читается хуже, чем в стиле "через_подчеркивание" или "в-стиле-лиспа". В некоторых языках идут на компромисс: GetURL, getURL, GetUrl, get_url, GET_URL — одно и то же, каждый форматирует себе в соответствии своих фломастеров.
Я это всё к тому, что и С#, и Java — языки не шибко выразительные и стройные, как их не крути. Поэтому, с большой или с маленькой буквы в них приватные методы — фактически пофиг: это такой же костыль как и венгерская нотация. Т.е. это вторично, здесь важно просто наличие хоть какого-то стандарта, и лучше общего для всех, т.е. то, что сказала партия, будь то мелкософт или сан с оракулом. В жабе, насколько я имею представление, особенно не возникает вопросов по поводу корпаративных стандартов, там особо нет смысла что-то своё выдумывать — легче не станет.
Если нам не помогут, то мы тоже никого не пощадим.
Пишите как в Delphi -- все с большой буквы.
