LINUX.ORG.RU

Сишный быдлокодер.

 ,


0

2

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

Что по вашему мнению есть быдлокод, а что нет? Лично у меня чувство неопределённости, так как нет того кто ткнёт пальцем в кусок кода.

И у меня развилась мания, я переписываю всё заново. Что почитать/посмотреть про хороший стиль программирования на С? Как блин понять то, что твой код нормален или он быдлокод? И да у меня одного привычка переусердствовать с if() {} else{};? Приветствуются куски кода/целые проекты с указанием быдлокод/идеальный код.

И да, я немного пьян.

Мне конечно стыдно, но вот https://github.com/fedor-elizarov для примера, там мало конечно но думаю хватит и этого, остальное локально храню. Ну и cast beastie, ты просто адекват и сишник.

★★★★★

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

Ответ на: комментарий от quasimoto

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

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

Лучше на русском чем на кривом не русском.Наверное так.

Не так. Лучше на хоть каком-нибудь английском чем на русском.

thesame ★★★★
()

«Нормального» не бывает. Ничего. А твой код вполне себе нормален для промышленного конвейерного производства ПО. И реакция i-rinat нормальна для процесса производства. Ты исправишь его замечания и QA пропустит твой код в основную ветку. Все метрики (показатели, параметры) процесса в норме, все счастливы. А вот идеальный код не нормален! review не выявил замечаний - у всех проблемы. Да, это у меня баттхерт.

В UNIEN уже куча кода и это только для инициализации, даже так - для начала инициализации, ну, дернул инит библиотеки, а уже килобайты текста. А до дела еще не дошло. А где тот бриллиант, который ты хочешь показать миру?

Уже успокоившись, ытерпрайз: слишком большой diff для одной feature, повторного использования кода нет, QA не одобрит. Предложения - использовать библиотеки для чтения конфигурации, разбора текста, отладочного вывода, отображений строка->функция. Или сделать свои велосипеды, пригодные для повторного использования. Или ты китаец?

Хоть программирование - это не искусство, но чувство прекрасного оно вызывает. Этим и надо руководствоваться в первую очередь, а не спрашивать других. Я щитаю.

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

Интересно расказал.

повторного использования кода нет

Верное замечание.

но чувство прекрасного оно вызывает

Три литра чая и килограммовую печеньку тебе.

а не спрашивать других

Чужое мнение иногда бывает очень интересно послушать.

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

Чужое мнение иногда бывает очень интересно послушать.

Да. «нормальный», «быдлокод» - это оценки, это невроз как слушателя, так и говорящего. А вот узнать как [бы] поступил другой человек - это, да, интересно.

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

Опять выкинешь весь код?

Производительность/экономичность:

  • unien_load_file вычитывает ВЕСЬ файл сразу.
  • unien_read_conf каждый раз мусолит всю память.
  • частота вызова malloc напрягает.
  • unien_read_conf не масштабируемая в любом смысле.

Много extern, мало static. Много signed.

Много пустого по вертикали, и мало по горизонтали. Тебя самого твой стиль устраивает?

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

Много пустого по вертикали, и мало по горизонтали. Тебя самого твой стиль устраивает?

Оллман одобряет, а остального не надо.

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

Знаешь, что я тебе скажу. Со мной всегда спорили о написании кода.

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

Ты не осилил сишку. Ты не умеешь писать функции вообще прям тотально - твой код 99% избыточности.

Ты не представляешь что тебе надо: Что надо писать в конфигах, какие тебе нужны статусы и т.п. Ты пытаешься написать обёртку как в сдл, но не сдл.

Поэтому возьми тупо и напиши какую-нибудь одну подсистему. Хочешь видео - пиши рендер.

Пиши так, чтобы он был понтов - забей на всё. Забей на тупые копирайты в файлах, бесполезные комменты, попытки запилить сразу «расширяемую систему» непонимая нихрена. Пили и изучай сишку.

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

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

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

Если выкинуть переход на личности и прямые оскорбления, то мне понравилось. Сначала понты, потом остальное.

С другой стороны, эмоционально окрашенные события лучше запоминаются. Прокодер99, ты своим веселым хвостиком окрашиваешь унылую серую тему ЛОРа.

fopen ★★
()

Топикстартер, а русский для тебя родной?

В исключении тех случаев, когда нужно задействовать
глобальные переменные, в этом случае для них должен быть реализован
интерфейс в виде функций и как минимум двух, для задания значения
переменной и для возврата значения, такие функции должны быть,
реализованны в UNIEN_utilities.c который также по умолчанию в виде
api должен быть доступен любой части UNIEN посредством подключения
заоловочного файла UNIEN_utilities.h

Лучше на русском чем на кривом не русском.Наверное так.

Пока что получается на кривом русском.

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

Вертикальная экономия(не актуальная лет 30) и работа сделала из них анскиллед да.

А так да, кореутилс житчайщий быдлокод. 80% гнукода было написанно лет 20назад и не переписывалось - они до сих пор тянут type f(a) type a и подобное ради того, чтобы не переписывать код.

Отчасти переносимость и написание кода 20лет назад с убогими конпеляторами оправдывает, но это не тот код, который надо считать вменяемым.

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

Это проведение говорит ему - «не слушай анскиллед, который пичкают тебя всяким фуфлом, пугают глобальными переменными и прочим, каким-то мистическим api и иной ересью», а он не понимает.

Да и какая разница на чём писать, если комменты в 98% случаев не нужны.

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

А ну да, свичи на 400строк посреди мейна для разбора аргументов - это так круто.

Ещё сотня строк на форматирование времени и т.п.

А так же j-- - меня всегда это добивало, почему j--, а не --j.

int i = ARGMATCH (q_style, quoting_style_args, quoting_style_vals);
        if (0 <= i)
          set_quoting_style (NULL, quoting_style_vals[i]);
        else
          error (0, 0,
         _("ignoring invalid value of environment variable QUOTING_STYLE: %s"),
                 quotearg (q_style));
int i = ARGMATCH(q_style, quoting_style_args, quoting_style_vals);
if(i < 0)
   error(0, 0, _("ignoring invalid value of environment variable QUOTING_STYLE: %s"), quotearg(q_style));
set_quoting_style (NULL, quoting_style_vals[i]);

А уж если вынести ошибки, выпилить ущербанские макроссы и запилить все ошибки в argmatch, то код был бы в 1 строчку, вместо 10.

Да и сам argmatch() написан как щит.

И таких примеров тысячу на каждой строчке.

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

Ох тыж ёперный театр! Ну и говнище же ваша сишка! Это же получается, что switch/case не более чем goto с метками! Можно прыгнуть прямо внутрь цикла, ну и дерьмо !

s9gf4ult ★★
()

самое главное - тщательно продумать алгоритм в голове. не смейтесь, это действительно важно, потому что без четкого видения проблемы возникают и костыли, и хреновые архитектурные решения (т.е. «быдлокод»). Ну и книжек почитай:

http://fabiensanglard.net/c/

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

во-первых, этот трюк остался со времен динозавров; новый компилятор вряд ли даст скомпилировать такой код, пропуская вход в цикл

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

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

Только ты забываешь, что для того, чтобы представлять - тебе надо понимать, причем не только сишку. А чтобы понимать - тебе надо пилить. Поэтому сначала пилишь - потом понимаешь.

Сначала ты пилишь сложные, но маленькие системы, их отдельные елементы. Когда научишься ковать винтики, шестерёнки - только тогда тебе надо пытаться собирать часомех и то получится с 55раза. А шистерёнки и винтики ты вообще будешь кувать лет 5.

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

Реально? Очередной посстудент? Хочешь батл?

Ну давай, какой оптимальный алгоритм для «парсинга конфига»? Ведь потом автор будет делать консольку и этот конфиг ой как вплывёт у него.

procoder99
()

А че никто не вспомнил «Совершенный код»?

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

Пока это самый компактный, простой и минималистичный ЯП. Приэтом он является самым предсказуемым, быстрым( по всем параметрам сразу) и мощным ЯП в этом мире.

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

Этот ЯП основа всего, код транслируемый из него исполняет и транслирует 99% остальных ЯП. В конечном итоге на нём написанно 90% кода в мире( тут ещё правда и плюсы, но они тупо си с классами).

procoder99
()

Я Ъ, поэтому комментирую только те куски, которые здесь постили.

1. Быдлокодер как начинающий. Ты изучил синтаксис, но ещё не умеешь применять к месту все конструкции (уже говорили про enum и указатели на функции). Это не страшно. Попишешь год-другой, понаступаешь на грабли, и научишься. Но тебе никто не указал на ошибку проектирования в инициализации. init_video, init_audio, к гадалке не ходи, выставляют какие-то признаки того, что они проинициализированы. Подозреваю, что в глобальных переменных. И во всём остальном коде ты будешь обречён их проверять на каждый чих (не говоря о том, что не все комбинации параметров будут валидными, что добавит тебе ещё головной боли). Это к вопросу откуда появляются этажерки if-else. Грамотному проектированию научиться сильно сложнее, и уж точно не многократным переписыванием с нуля.

2. Быдлокодер как состояние души. Пиши дальше, и когда прикрутить фичу станет непросто/неудобно не ленись переделать то что тебе мешает. Быдлокодеры этого типа лепят костыли на костылях (потому что лень, сроки, «там всё настолько запущено, что надо будет потом переписать с нуля») пока не приводят проект к полной невозможности внесения изменений за разумное время. Не делай так.

Таки да, плюсы придумали для решения многих проблем традиционного сишного быдлокода :)

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

Ещё:

enum blah {
    ...;
};

struct unien_config {
    bool debug, exit_to_error, ...;
    bool init_video, init_audio, ...;
    enum blah ...;
    char foo[10];
    char bar[MAX_STRING_LEN];
    wchar_t *text;
    ...
};

// если оно per-process
struct unien_config my_unien_config;

// per-thread, ЕМНИП
__thread struct unien_config my_unien_config;

error_code_t unien_read_config(const char *path, struct unien_config *config)
{
    // читаем файл path, заполняем config.
}

error_code_t unien_init(const struct unien_config *config)
{
    // смотрим в config и инициализируем подсистемы, опять же, их состояние --
    // в структуры, их объекты -- либо выше на стеке, либо в области данных если
    // они глобальны.
}

void some_top_level_func()
{
    ...

    // если не глобально
    struct unien_config config;

    unien_read_config(path, &config);
    unien_init(&config);

    ...
}

тут везде malloc быть не должно (если только для wchar_t*). Правда, скорее всего окажется так, что по появлению этих самих video, audio они будут устроенны совсем не так и придётся всю инициализацию выкинуть — лучше начинать с более важных подсистем (опять же, если не осилишь, то лучше споткнуться сразу о них).

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

если пилить, не понимая - далеко не продвинешься. поэтому надо сначала документацию читать, потом писать и читать доки одновременно

mazdai ★★★
()

Выше написали и я увидел вчар - вчар не упал. У тебя параметры онлилатиница, а если локаль утф - чекай последний бит, чтобы отделить ascii от утф8.

Утф декодер пишется как-то так:

#include <bits/byteswap.h>
#include <stdint.h>

typedef union {
    struct {
      uint8_t a, b, c, d;
    } u8;
    uint32_t u32;
} v8_t;

static uint8_t utf8_d[] = {
  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
  0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F,
  0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F,
  0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F,
  0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F,
  0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E, 0x5F,
  0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x6F,
  0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7A, 0x7B, 0x7C, 0x7D, 0x7E, 0x7F,
  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
  0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F,
  0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F,
  0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F,
  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
  0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F,
  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};
static uint8_t head_to_len[] = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 3, 2, 2, 2, 2, 3, 3, 4, 0};
static uint8_t len_to_l[] = {32, 18, 12, 6, 0};

static inline uint64_t utf8_decode_char(char ** p_str) {
  v8_t ch = *(v8_t *)*p_str;
  uint64_t ret = 0, oct = head_to_len[(ch.u32 & 0xF8) >> 3];
  ch.u32 = __bswap_32(ch.u32);
  *p_str += oct;
  
  ret += (uint64_t)utf8_d[ch.u8.a] << 0;
  ret += (uint64_t)utf8_d[ch.u8.b] << 6;
  ret += (uint64_t)utf8_d[ch.u8.c] << 12;
  ret += (uint64_t)utf8_d[ch.u8.d] << 18;
  return ret >> len_to_l[oct];
}

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

Ну и нет проверок ниначё, хотя если подлотать его немного - он будет самым быстрым в мире.

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

Я пилю, но ты проходи мимо. И второе тоже пилю - всё будет.

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

Ну вот я не понимаю доки - доки написанны для анскилледа. Мне интересней читать код - код я понимаю лучше, намного.

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

Это либо аля KR для Сей, либо аля страутруп для плюсов - обе слишком изимодны. Какие-то трудны «высокого» уровня по всяких «алгоритмам» написанны теми, кто никогда кода не писал, а именно жалкими теоретиками.

Читать него - всё щит.

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

вот листинг

я смотрю у тебя избыток ентеров... отсылай их в бедные страны, там люди без них мучаются.

Rastafarra ★★★★
()

Экономьте строчки. Есть конечно разные стили, но вот так

void foo(){
...
}
ИМНО лучше чем вот так
void foo()
{

...

}

Вы видите только то, что на экране, чем больший фрагмент кода влезает на экран тем меньше приходиться листать, и тем эффективней работа. Кроме того, один блок кода (тело цикла например) не должен превышать размер экрана. Иначе, одна } не в том месте, и здравствуй ночь насыщенная отладкой;-)

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

Отцы писали во втором стиле тогда, когда терминалы были 80x24. А уж сейчас экономить одну строку на теле функции просто глупо.

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

А сейчас терминалы 24x80 - поэтомул юди и экномят вертикаль. Вобще 100строк в нормальном проСишном стиле примерно равны 700-1000строк в щитС++ стиле и прочих какахах.

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

Т.е. на каждую функцию глупышка в среднем сливает строк 1к1, либо 2к1(код к оверхеду), что выливается в пичальность.

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

А сейчас терминалы 24x80

Ну, у тебя-то да.

100строк в нормальном проСишном стиле примерно равны 700-1000строк в щитС++

Это твой-то стиль - «проСи»? Не смеши мои тапки.

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

«Да, были люди в наше время, не то что нынешнее племя...»?

Это мое сугубо личное мнение, я же не программист. Но я тут давеча почуйствовал себя полным, абсолютным мудаком: неделю пытался понять где у меня ошибка, перелопатил все чуть ли не до либси, а оказывается скобочка закрывающая в цикле (который на два экрана) не там стояла... Писать комменты после каждой скобки что она закрывает что ли? Дык я итак чуть ли не каждую строчку уже комментирую, больно алгоритм мозговыносящий.

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

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

«Да, были люди в наше время, не то что нынешнее племя...»?

Нет. _Так_ экономить строки не имело смысла даже тогда, когда строки нужно было экономить.

я же не программист

Отмазки.

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

Был когда то тут срач, какой стиль расстановки скобок лучше. Этот стиль не «мой», а один из канонических.

Но я вааще ивзращаенец, я и так пишу

struct Ray{ vctr<3> old_r, r, n; double tau; };
и так
template <typename T> void foo(const T& x){...}
Не обращайте на меня внимания;-)

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

Вы хотите поговорить об этом?;-)

Чем же стиль ТС-а (или он называется К&R ЕМНИП) лучше экономного? Потому что у меня напр. не вызывает никаких проблем увидеть где там функция начинается.

AIv ★★★★★
()
Ответ на: комментарий от i-rinat

это уже как-то устоялось.

имхо, это «устоялось» - зло, и без этого в C никакая проверка типов, я всё-таки сторонник разделять bool и целые

Не смешивай tab'ы и пробелы. Определись.

да там ваще чад кутежа с форматированием, доктор прописывает юзать нормальный редактор

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

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

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

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

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

И там конкретно анонимус кичился, что мрт верх «спасения жизней».

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

Вы хотите поговорить об этом?;-)

Нет. Какой смысл обсуждать очевидное?

Чем же стиль ТС-а (или он называется К&R ЕМНИП)

Это не K&R.

у меня напр. не вызывает никаких проблем

А { на отдельной строке вызывает проблемы? Доопустим, у тебя экран на 40 строк - у тебя проблемы от того, что ты потеряешь одну-две?

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

Уфф... Читал сейчас Леннарта. Прикольно. Ощущение, что пишет на ассемблере. Плотность идеи на одну строку очень низка, но зато скорость потока строк высока. Потом заглянул в ветку udev. Разница ощущается сразу. И не из-за «{». Характер авторов разный, чувствуется.

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