Discusion: Языки с и без чувств. к регистрам?
Кому какие языки более по душе и почему!
- языки с чувствительностью к регистру
- языки без чувствительности к регистра
мой ответ:
языки без чувствительности к регистра
так как недопускаеш простых ошыбок которые надо искать 4 часа!
и потомучто я юзер виндовса :)
Кому какие языки более по душе и почему!
- языки с чувствительностью к регистру
- языки без чувствительности к регистра
мой ответ:
языки без чувствительности к регистра
так как недопускаеш простых ошыбок которые надо искать 4 часа!
и потомучто я юзер виндовса :)
вобще то компилятор обычно выдает в какой строке какой косяк, искать приходится не долго
с регистром лучше, если один и тот же тип объекта нужно держать в разных переменных. ИМХО
ИМХО, так делать не надо, потому что такая ошибка может скомпилироваться, а это сразу усложнит её поиск.
не это имел ввиду...
допустим есть глобальная переменная ID (уникальный номер записи)
и есть функция агрументом которой тоже является уникальный номер записи, но не глобальный а некий вычисляемый
тогда удобно записать func (int id)
т.е. у меня UIN записи всегда называется id, но в зависимости от его "глобальности" он может быть в разных регистрах
Лично меня раздражает, когда я смотрю на программу, где имена могут быть написаны по-разному.
ЗЫ. Лучше бы опрос замутил.
Языки чувствительные к регустру должны быть обязательно компилируемыми, а для трасляторов пойдут любые.
Лично меня раздражает, когда я смотрю на программу, где имена могут быть написаны по-разному.
Простое и изящное решение этой проблемы сделано в Visual Studio 2005 (а может и в 2003й есть) для кода на VB.NET: там переменная всегда пишется в том виде, в котором её объявили. Если добавить к этому Smart Tabs, то неаккуратный код написать можно исключительно в рамках соглашения о кодировании. ;) Мне этот способ представляется наилучшим, ибо черновую работу должен делать редактор, и чем больше он её делает, тем лучше.
Языки чувствительные к регустру должны быть обязательно компилируемыми, а для трасляторов пойдут любые.
А компиялторы разве уже не трансляторы? )))
А какая принципиальная связь между компилируемостью или интрепретируемостью и регистрозависимостью? ))))
А какая принципиальная связь между компилируемостью или интрепретируемостью и регистрозависимостью? ))))
Ну мне это представляется так:
Компилируемые языки неотемлимо связаны с системным программированием, и поэтому, для простоты поиска ошибок, наглядности исходного текста и размеров самой программы лучше использовать языки с чувствительностью к регистру символов. А транслируемые языки вполне могут обойтись и без этого.
К моему стыду ни разу не запускал VB - ни 2003, ни 2005 :) С момента перехода на С++ 8 лет назад, вообще никакими другими языками не пользовался для решения конкретных задач (если не считать CAD-овские).
Кстати, форматирование у нас в конвеншн тоже входит - четко прописано где и какой отступ делать, как и в каком случае выполнять перенос.
Компилируемые языки неотемлимо связаны с системным программированием
Э, ну большинство языков компилируемых не предназначенны для системного программирования и юзать их для этого дела тяжело. Пожалуй только С наиболее предрасположен к этому.
для простоты поиска ошибок, наглядности исходного текста и размеров самой программы лучше использовать языки с чувствительностью к регистру символов.
Дык повторюсь, интерпретируемым языкам разве не нужен поиск ошибок и стандарты кодирования?
А транслируемые языки вполне могут обойтись и без этого.
И тоже повторюсь - с каих пор компилируемые языки перестали быть транслируемыми? )))
Компилируемые языки неотемлимо связаны с системным программированием, и поэтому, для простоты поиска ошибок, наглядности исходного текста и размеров самой программы лучше использовать языки с чувствительностью к регистру символов. А транслируемые языки вполне могут обойтись и без этого.
Существует два вида трансляторов: компиляторы и интерпретаторы.
Компиляторы - переводят программу, написанную на языке высокого уровня на язык низкого уровня (например машинный код) для последующего выполнения.
Транслятор - осуществляет непосредственное выполнение программы, написанной на определенном языке.
Может имелось ввиду второе понятие?
Тогда не понятен аргумент того, почему они "вполне могут обойтись и без этого".
Дык повторюсь, интерпретируемым языкам разве не нужен поиск ошибок и стандарты кодирования?
Действительно, всем языкам необходимо поиск ошибок. В своих рассуждения я отталкивался исключительно от языка "С" и все всех его синтаксических наследников.
[quote=aks]
И тоже повторюсь - с каих пор компилируемые языки перестали быть транслируемыми? )))
[/quote]
Да собственно не с каких.
Тогда чем же они "рулят"? Проаргументируйте
Поддерживаю. Такие вещи, правописание переменных с длинными именами (если ее смысл такой, что сократить название трудно, не потеряв его выразительности), проверка правильности скобок, убирание концевых пробелов, форматирование исходника и.т.п. -- это вообще не должно отвлекать программиста от программирования.
В Winsock'ах, например, есть тип SOCKET и функция socket. Что мне не нравится. А если мне нравится писать Socket вместо socket и т.п., что в общем соответствует общему стилю названия API функций? Я просто тогда напишу Socket, GetHostByName (gethostbyname -эточтотакоеигдетутграницыслов).
А вообще этот спор можно продолжать и продолжать, и все так и останутся при своём субъективном мнении.
Про WinAPI вообще отдельный разговор. Слово "ужасно" слишком мягкое, для характеризования соглашений об именовании в этих API.
Замечу, в .NET для соответствия CTS-правилам, в сборке не должно быть типов в одном пространстве имен, различающихся только регистром написания - именно из-за поддержки нечувствительных к регистру языков.
Я частенько преключаюсь между Delphi и C# и потому мне, в принципе, не важно восприятие компилятора к регистру, мне одинаково удобно использовать оба языка: приучил себя писать имена так, как их объявил (ну, редактор частенько помогает в этом).
Ну имена функкций винсокетов заимствованны из беркли сокетов. Так что они пишуться так как должны. А SOCKET - всего лишь дефайн в том регистре, каком принято в WinAPI дефайнить простые и не только типы.
Опять же - это все проблеммы тех, кто не правильно пользуется нэймингом.
По поводу - я хочу писать так, а не так. Вот это как раз плохо. Мне например ненравится что каждый пишет в том регистре каком ему вздумается. Все одинаковые сущьности по хорошему должны быть написанны в одном регистре, чтоб не путить других.
И это в целом правильная практика. Лучше, если правила именования будут выбираться так, как если бы язык был нечувствительным к регистру.