Re[3]: О синтаксисе языков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 09.01.12 08:10
Оценка: +1
Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, netch80, Вы писали:


N>>А зачем?

Ф>Дабы облегчить чтение кода.

Мне оно не облегчает, а усложняет, по крайней мере в пределах первых до 5 позиционных параметров. (Точная граница сильно приблизительна.)
Есть функции, которые знаешь наизусть и вызываешь единообразно независимо от места определения. Например, если говорить о системных и около того, то это open(), exit(), stat(), socket(), bind() и так далее. Вводить ещё какие-то имена параметров к ним... лучше в сад.

А вот если у функции может быть 1-2 обязательных параметра и дофига специальных на отдельный случай — вот тогда вводить имена для них — самое оно. И такие варианты стиля есть. Я не против видеть такое, например, в C++, но только в порядке "дополнительных" возможностей для параметров со значениями по умолчанию.

N>>В сложных случаях, да, оно полезнее. В простых — нет.

Ф>Полезно во всех ситуациях.
Ф>Не так давно правил багу, которую внесли при рефакторинге.

Ф>Вызов выглядел так:

Ф>GetParameters(c_QueryReportName);

Ф>А сам метод выглядел вот так: DbParameter[] GetParameters(string QueryText)


Честно говоря, нифига в этом примере не понял. c_ которое чего-то там Name это разве не строка? Почему нельзя передать его туда, где ожидается текст?
Или вопрос в том, что требовался текст запроса, а Вы передали его имя?
Прошу приводить пример так, чтобы не надо было гадать на кофейной гуще для его расшифровки.

С другой стороны, я могу привести в пример ещё кучу API, в котором возможно, например, перепутать параметры местами. И что?

И должен заметить, что рефакторинг вообще-то положено делать, предварительно обложив код тестами со всех сторон. И если баги подобного рода вносятся при рефакторинге, это значит, что для данного рефакторинга не были соблюдены входные условия. Более того, если следовать самому строгому определению, это вообще не рефакторинг, а какая-то ручная доработка.

N>>Но что Вы будете делать, если в следующей версии библиотеки кто-то переименует параметры в заголовочном файле...

Ф>Это будет свинство чистой воды. Однако нажму Ctrl+H и заменю код вызовов (с ребилдом и тестированием — максимум час).

Хорошо, приведу другой пример — ближе к моей практике. Стандартизация Posix определяет у функций набор параметров с их позициями. Имена не задаются. Если я возьму имя, которое вписано на NetBSD, а компиляция сорвётся на Linux, что мне делать? Или в языке в таком случае имя должно было быть фиксировано в определении интерфейса?

Я не отрицаю Ваши соображения полностью. Более того, я сам периодически использую такой стиль там, где это важно. Есть языки, которые позволяют такое (в первую очередь имею в виду Python, у него правила соответствия вызова определению функции тут достаточно гибки и при этом однозначны, чтобы не получить неожиданные эффекты). Но я бы не стал устанавливать это обязательным для всех случаев: вот это точно задолбёт.
The God is real, unless declared integer.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.