LINUX.ORG.RU

Аргументы за и против длинных имён функций

 , , ,


1

1

Пример


#ifndef cmouse_h
#define cmouse_h
#include "cengine.h"
#include "cevent.h"

/*     ==EVENT FUNCTIONS==     */

mouse* mouse_event_get();
void   mouse_event_update();
bool   mouse_event_evented();
bool   mouse_event_key();
bool   mouse_event_wheel();
bool   mouse_event_position();

vec2   mouse_event_position_xy(void);
float  mouse_event_position_x(void);
float  mouse_event_position_y(void);

vec2   mouse_event_position_xyrel(void);
float  mouse_event_position_xrel(void);
float  mouse_event_position_yrel(void);

bool   mouse_event_keydown_left(void);
bool   mouse_event_keydown_right(void);
bool   mouse_event_keydown_middle(void);

bool   mouse_event_keyup_left(void);
bool   mouse_event_keyup_right(void);
bool   mouse_event_keyup_middle(void);

bool   mouse_event_wheel_up(void);
bool   mouse_event_wheel_down(void);
bool   mouse_event_wheel_left(void);
bool   mouse_event_wheel_right(void);

/*==        STATE RUNCTIONS       ==*/

bool   mouse_state_key_left(void);
bool   mouse_state_key_right(void);
bool   mouse_state_key_middle(void);

vec2   mouse_state_position_xy(void);
float  mouse_state_position_x(void);
float  mouse_state_position_y(void);

vec2   mouse_state_position_xyrel(void);
float  mouse_state_position_xrel(void);
float  mouse_state_position_yrel(void);


#endif

Сабж.

Deleted

Последнее исправление: Deleted (всего исправлений: 1)

Я бы «position» на «pos» заменил.

Radjah ★★★★★
()

Ну против легко придумать. Раздуваешь файл, замедляешь код, упрощаешь жизнь крякерам и наоборот усложняешь легитимным программистам. Да даже читаемость у длинных однотипных имён хуже. А за?

anonymous
()

Ну ты спросил. Если это API - то конечно нужны, ибо это, считай, неймспейсы.

А то у тебя какой-нибудь position_xy встретится, и сам не поймешь, откуда он, и компилятор.

Можно чего покороче, типа аббревиатур mgxr_..., что б лучше все это смотрелось.

А во внутреннем коде, если это реально не мешает (опять, из-за конфликта имен) то, конечно, короткие.

PS #pragma once рулит :)

Deleted
()

Длинные имена проще делать однообразными. Однообразность снижает потребность в документации, а документацию мы пишем только в мечтах и когда рассказываем «рыбацкие истории».

Deleted
()

Всё не так.

1. У мышей бывает не только левая-правая-средняя-колёсная кнопки, т.ч. wheel_left_right_middle нужно убрать куда-то в аргументы.

2. up/down - всегда события, т.ч. либо _event либо _up_down убрать.

3. Если тебя интересуют координаты события, не нужно разносить его по ф-ям, т.ч. event_position - тоже убрать в аргументы.

4. x и y - всегда position, ввиду п.3 - убрать.либо _position либо _x _y,

5. Ещё, mousе нужно заменить на pointer — мало ли там чем оно управляется

6. и 2мерные координаты на минимум 4(вдруг в мало ли чем акселеро-, или ешё какой -метр)

7. И да, _up и _down - неправильные названия - кнопки могут нажиматься в разные стороны. Но из короткого на ум приходит только on-off, что не очень понятно.

Итого, останется pointer_event(кучатеталей), pointer_state(или _keys, _position), и может быть что-то из непонятных ф-й первого абзаца про события.

DonkeyHot ★★★★★
()

Всем спасибо, ну жёстких аргументов против не услышал, но стоит ещё продумать помимо соглашения об именованиях и о соглашении о сокращении и что бы это не входило в конфликт. Пока что на практике несмотря на большую сомнительность длинных функций нахожу их более приемлемыми, но повторюсь надо продумать сокращения. Да можно всё зазвать очень коротко и подразумевать что сокращения в функции нивелируются при использовании пониманием из контекста что это за сокращения если мы работаем с 3d/2d и там dir это direction если с файлами то dir это directories, это логично, но требует долгого выбора имени порой. Короче так как кроме меня самого это использовать никто не будет можно вообще как угодно делать, но всё же )))

К слову, а кто может что порекомендовать прочитать про проработку архитектуры API , договорённости и всё такое. У меня лично всё просто, если есть вариант сделать функцию без аргументов то тому и быть, название функции максимум 4 слова агрументов функции до 4 иначе либо данные в структуре либо функция делится на две. Но это всё в лоб и просто. Так как критиковать меня кроме меня самого некому, хотелось бы почитать что-то по проработке API.

Отмечу как решённую.

Deleted
()

Ну так сделай покороче: mouse_event_evented → MEevented, mouse_state_position_y → MSposY, mouse_event_keydown_left → MEkdL и т.д., и т.п.

Читабельность от этого только лучше!

anonymous
()

За отсутствием модулей в Си приходится писать так. По-другому не прокатывает.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от anonymous

упрощаешь жизнь крякерам

Мамка не учила статической линковке и вырезанию символов из бинарника?

anonymous
()

Это еще не длинные, а как раз норм.

goingUp ★★★★★
()
Ответ на: комментарий от anonymous

MEkdL

Ну уж нет, пусть в #define оборачивают кому надо

Deleted
()
Ответ на: комментарий от Deleted

Для единообразия,3d, там практически всё float

в драйверах float нет, да и физически тоже - у каждой точки целочисленные координаты.

anonymous
()
Ответ на: комментарий от anonymous

замедляешь код, упрощаешь жизнь крякерам и наоборот усложняешь легитимным программистам.

Что за бред? После компилятора ничего этого не останется. Нет на тебя Царя.

Hartmann
()
Ответ на: комментарий от anonymous

Нормальные люди подрезают отладочную информацию для сокращения размера релизного бинаря, один хрен туда никто не полезет если проект открытый и есть сорцы. А если закрытый то ещё и всякими упаковщиками/крипторами пройтись могут.

Hartmann
()

Ни длина, ни краткость — не самоцель. Важна читаемость, понятность и единообразие.

Приведённый в ОП пример — вполне хорош (хотя я удваиваю оратора, который предложил заменить position на pos).

hobbit ★★★★★
()

Конкретно здесь какой-то overcomplication с разделением кнопок и осей. Посмотри как евенты сделаны в SDL, например.

А в общем только по сабжу - для говённого C более чем нормально. А в нормальных языках это будет event.mouse.pos.x, при этом в реальном коде будет использоваться просто mouse.pos или pos.

slovazap ★★★★★
()

Если файл про мышь, то mouse_event можно смело заменять на ME, а mouse_state на MSt, position на pos и т.д.. Но только если это не торчит наружу, и кроме мыши там нет ничего похожего. Если это торчит наружу, это не кресты с неймспейсами и/или там не только мышь, то заменять нельзя.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 3)

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonymous

Ты давно код в отладчике открывал?

Давно. Поэтому он и не замедляется от длинных имён, т.к. вне отладчика.

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

подобные имена функций, да, вот именно такие - нормуль. Мне нра, няяя.

I-Love-Microsoft

Я ожидал, что ты будешь топить за венгерскую нотацию.

i-rinat ★★★★★
()

Главный аргумент против - это то, что так сказано в священном писании

C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable ``tmp``, which is much easier to write, and not the least more difficult to understand.

Reineke
()
Ответ на: комментарий от Reineke

A C programmer would call that variable ``tmp``, which is...

Это про локальные переменные, а не про глобально доступные идентификаторы.

i-rinat ★★★★★
()

ходишь по лезвию

стандарт не гарантирует поддержку внешних имён длиннее 31 символа

anonymous
()
Ответ на: ходишь по лезвию от anonymous

«Программирование на C подобно быстрому танцу на полу, только что натёртом воском, среди людей с острыми бритвами в руках.»

Waldi Ravens.

Deleted
()
Ответ на: комментарий от Deleted

Танцевать на скользком полу с бритвами лучше, чем валяться в канаве...

Больше ЯП-то и нет!

anonymous
()
Ответ на: комментарий от anonymous

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

Я.

Deleted
()
Ответ на: комментарий от Deleted

К слову, а кто может что порекомендовать прочитать про проработку архитектуры API , договорённости и всё такое

хз что читать. По удачному опыту: делай тесты, и юнит, и интеграционные, делай примеры использования либы. Много-много-много примеров и тестов. Когда ты сам начнешь пользоваться своим API, ты сделаешь удобный API. А до этого - ставь ‘v0.0.1’ версию :)

Deleted
()
Ответ на: комментарий от Reineke

+ более того это истерически как по мне желательно в реализации функций и в main причём если функция не велика можно иметь одно наименование в разных контекстах через {...} изоляцию, но только если всё обозримо сразу

#include <stdio.h>

int main(int argc, char *argv[])
{
    int tmp = 10;
    printf("%i\n",tmp);

    {
        float tmp = 10.01;
        printf("%0.2f\n",tmp);
    }

    printf("%i\n",tmp);
    return 0;
}

Но всё это не про именование внешних функций, суть как по мне их в том что они должны быть однозначными, не всегда это возможно, но лучше к этому стремиться. Хотя я хз я не программист )

Deleted
()
Ответ на: комментарий от post-factum

А на шестой день б-г придумал ООП

Не, это он сделал, когда увидел, что в аду не хватает отдела обслуживания программистов.

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Ответ на: комментарий от Deleted

Много-много-много примеров и тестов.

Вшплюс, без них никак

Deleted
()
Ответ на: комментарий от conalex

простота - это хорошо

Именно, вариативность мне даётся адски я не запоминаю. А так норм.

но что там у тебя с ошибками?

Сейчас все ошибки фатальные. assert assert`том погоняет, и оно внутри.

Deleted
()
Ответ на: комментарий от conalex

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

В любом случае я не тороплюсь, это на годы для меня. К слову вчера залил билд в Steam первый раз и прифигел что у них оверлей работает сам по себе я думал его прикручивать надо, а валв как то оверлей игровой сам вставляет поверх любого OGL окна, прикольно ))) мне нра ) Но не совсем понимаю как это работает, наверное перехватывается вызов отрисовки и рисуется поверху потом ведь runtime то там у них свой.

Deleted
()

Нет времени перечитывать весь тред. Царь уже пришёл?

burato ★★★★★
()
Ответ на: комментарий от anonymous

Если ты про steam, то да штольмана на меня нет, если ты про скрытие обработки ошибок, то главное что бы они были обработаны, а где и как дело десятое. Естессна когда всё будет ок, фатальными должны остаться только действительно фатальные ошибки, остальное же просто уходит в warning. Да и вообще для ошибок есть extern err

Deleted
()
Ответ на: комментарий от LongLiveUbuntu

2 штуки много, 3 штуки - очень много.

Тогда только на Haskell писать. Там у функции не больше одного аргумента может быть.

monk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.