http://catb.org/jargon/html/writing-style.html

не совсем ответ на вопрос, но если проникнуться, его не станет

Всё просто. Используя Linux API пишут суровые бородатые хакеры, которые способны прочитать документацию и запомнить, что значат сокращение. А функции Qt, WinAPI и прочих поделий, предназначенных для написания (относительно) более хай-левел софта, должны быть понятны любому обиженному мозгом быдлокодеру. Получается этакий барьер, чтобы не доросшие не лезли куда не надо, ну и влияние традиций :)

И пиши как дурак вместо ioctl какой-нибудь InputOutputControl_WithSomeTricks(...) :)

:D

legacy код довольно специфичен, как и код в ядре

сравнивать_гну-шный_кодинг_стайл_на_си сКодингСтайломКомпанииТрольТехТоЖеНеСовсемКорректно.

> В данном случае под Windows API я имел ввиду читабельные в плане названия функции типа CreateFileA, CreateDirectoryW и т.д., а не хернь, которая используется уже внутри этой ОС.

Ленивые дядьки, которые прекрасно знают, что делают, и отлично могут пользоваться как грепом, так и ctags/cscope/etc находят удобным использование простых и коротких имён функций, таких как mkdir, а вот писать CreateDirectoryW - им западло.

Видимо, наследие времён и привычек, когда гарантировалось различие только шести букв идентификатора :)

...

На Фортране совсем весело было в библиотеках. Имена максимум из шести букв, из них три - для указания типа или библиотеки :)

Потому что это write only код?

Тут даже не в конкретном стиле дело - название сишной функции foo_bar в зависимости от принятого в конкретном языке стиля будет выглядеть как fooBar, FooBar, foo-bar (какие там ещё варианты бывают?), а в том, что предпочтительнее - максимально понятное, но длинное название, либо кратко-ёмкое, и это уже дело вкуса и аудитории. Это как в русском языке - фразы «забубенить эту хреновину» и «смонтировать прибор для газификации луж» могут значить одно и то же, только вторая понятна всем, а первая - тем, кто в курсе предметной области и что это значит в конкретном контексте.

Ну и что лучше:

int fd = open(fname, O_CREAT | O_TRUNK, perms);

HANDLE fd = CreateFile(fname,GENERIC_WRITE,NULL,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);

Разрабы Unix знали свое дело.

Сокращенные имена функций позволяют вместить больше в одну строчку. Это сейчас у нас высокое разрешение и широкоформатные мониторы, а когда давались имена этим функциям, такой роскоши не было.

> creat(), fcntl(), dup()

Зачем букву у create отрезали - для меня загадка. Короткое название обычно запоминается к концу чтения мана. Код с короткими именами не только быстрее печатается, но и проще читается! При условии, что читающий видит эти функции не в первый раз. Если же просто вышел погулять в чужой код, то по длинным именам можно быстрее составить представление о том, что там происходит.

Ты уверен, что отвечаешь именно на тот вопрос? :}

Блин, я уже не в чем не уверен :/ Мне показалось, что ТС говорит, что WinApi лучше, чем сисколлы Unix. Надо больше спать, да.

Вердикт

После прочтения http://lxr.linux.no/#linux+v2.6.32/Documentation/CodingStyle http://www.kernel.org/doc/Documentation/CodingStyle http://catb.org/jargon/html/writing-style.html и комментов я понял, что это было связано как с временем разработки, когда физически не получалось работать с длинными именами функций и других элементов языка, а также явилось своеобразной «визиткой» процесса разработки системного уровня, когда названия укорачивались для быстроты и удобства чтения. Удобство в данном случае имеет место лишь тогда, когда программист прочитал ман по интересующей его вещи и знает как расшифровывается аббревиатура (ioctl - Input Output ConTroL, например). А это, кстати, заставляет задуматься, что именование функций какого-либо api в таком «аббревиатурном формате» (грубо сказано, но все же) приведет к тому, что все использующие его будут так или иначе читать мануалы, что есть хорошо. У меня давно назревала своя конвенция именования для C++. Как-нибудь собирусь с мыслями и опубликую ее.

>Удобство в данном случае имеет место лишь тогда, когда программист прочитал ман по интересующей его вещи и знает как расшифровывается аббревиатура (ioctl - Input Output ConTroL, например).

Как будто программист, увидевший в коде этот InputOutputControl без чтения манов легко поймёт, что с ним делать.

Все таки больше вероятность, что мимо манов не пройдет.

chldctl --sleep

>Код с короткими именами не только быстрее печатается,

Вы путаете программиста и машинистку. Большая часть усилий при разработке тратится вовсе не на набор кода + автодополнение никто не отменял.

но и проще читается!

Тоже неправда, порой имена отличаются на одну букву или как lockf/flock, что совсем не отражает специфики.

При условии, что читающий видит эти функции не в первый раз. Если же просто вышел погулять в чужой код, то по длинным именам можно быстрее составить представление о том, что там происходит.

UNIX-API - это скорее тяжёлое бремя, которое приходится всем нести в силу очевидных причин. От полного отвращения его спасает только исключительная важность, поэтому все знакомы и привыкли. Если Вы так будете писать свой код, то человек, который захочет в нём что-то поправить/разобраться потратит значительно больше времени, нежели с
QT/Java/Etc-похожим API.

> UNIX-API - это скорее тяжёлое бремя, которое приходится всем нести в силу очевидных причин. От полного отвращения его спасает только исключительная важность, поэтому все знакомы и привыкли.

Хорошо, а предложения есть? Как теперь называть fcntl,ioctl,open,close,read,writе,exit?

Если Вы так будете писать свой код, то человек, который захочет в нём что-то поправить/разобраться потратит значительно больше времени, нежели с

QT/Java/Etc-похожим API.

Это если человек - Qt/Java-coder.

Ну как бы ioctl, fcntl - все знают какбы, да. Но а если пишете код, неужели свои функции/классы также зовете?

>Хорошо, а предложения есть? Как теперь называть fcntl,ioctl,open,close,read,writе,exit?

Конкретно эти - только так, уже никак не переименовать. А в целом названия функций (и переменных) - это искусство, которому нужно учиться, которое приходит с опытом. Здесь нет точной инструкции, как и нет руководства по «рисованию шедевров живописи». Можно лишь почитать рекомендации, например, Макконнелла.

У меня на первом-втором курсе была своя коллекция дефайнов, в частности:

#define cw CreateWindow

В то время я ничего не знал про ОС Linux, ну разве что о том что она существует. Хз, может быть это и хорошо что не нашу группу отдали на растерзание одному линуксоиду с пятого курса, преподававшему C под Linux а не под Windows.

Раньше не было сред разработки с автокомплитами, код_ассистантами, тривью браузерами, код_эксплорерами и прочими панельками. Писали все вручную по памяти.

> Раньше не было сред разработки с автокомплитами, код_ассистантами, тривью браузерами, код_эксплорерами и прочими панельками. Писали все вручную по памяти.

не может быть О_О

ты б еще про umount спросил %)