1. Си / Говнокод #4905

    +137

    1. 1
    2. 2
    3. 3
    4. 4
    if (MACaddress == 0)
    		MACaddress = pAdapterInfo->Address [5] + pAdapterInfo->Address [4] * 256 + 
    					pAdapterInfo->Address [3] * 256 * 256 + 
    					pAdapterInfo->Address [2] * 256 * 256 * 256;

    Запостил: xynta, 12 Декабря 2010

    Комментарии (22) RSS

    • нахуя?
      Ответить
    • так а где говно?

      ну хоть бы уже куда комментарий "лопата" добавляли.
      Ответить
      • Говно в том, что число собирается по байтам таким кривым образом.
        Ответить
        • почему кривым?

          это стандартный портабельный способ собирания целого числа из байтов, работающий в независимости от strict alignment и от endianess. "стандртный" способ. я такой код (с мелкими вариациями) вижу почти каждый день.

          и меньше писать по сравненю со сдвигами, потому что для сдвигов нужно еще и конвертировать каждый байт из памяти в unsigned int - иначе обрезание происходить будет.
          Ответить
          • а чего маленький циклик не забабахать? от 2 до 5
            Ответить
            • Разворачивание циклов — это оптимизация по скорости. Зачем нам лишние счётчики и проверки условий?
              Ответить
            • так а на кой? этот код пишется раз, а потом он просто работает. это может народу с непривычки в глаза бросается, но тем кто сетевые сервера и протоколы делает, этот код выглядит как "2*2=4"

              да и цикл то как бы проще не будет. доп переменная понадобится. или две (для множителя/сдвига). народ пытается что бы простое обращение к памяти было как можно проще, и уж точно без flow control. разворачивание циклов оптимизатором тоже не гарантируется.
              Ответить
    • Будь адрес десятибайтовым, задолбались бы умножать на 256.
      Ответить
      • Можно оптимизировать по схеме Горнера:
        MACaddress = pAdapterInfo->Address [5] + 256 * (pAdapterInfo->Address [4] + 
        256 * (pAdapterInfo->Address [3] + 
        256 * pAdapterInfo->Address [2]));
        Задолбается тогда автор скобки считать!
        Ответить
    • Да вроде нормальный код. Разве что лично я предпочитаю использвать "(1<<8)" вместо "256" и "(1<<16)" вместо "256*256" соответственно (конкретно в данной ситуации я бы операцию умножения вообще не использовал, т.к. операции сдвига вполне хватает)
      Ответить
      • Кстати как раз в данном случае битовые сдвиги действительно нагляднее, чем умножение.
        Ответить
    • ололо
      шифтов мы не проходили
      Ответить
      • Не использование сдвигов - не повод ни смеяться, ни выкладывать код сюда ;)
        Ответить
        • а умножение на 256 три раза -- повод?
          Ответить
          • Нет. И я уже, кажется, косвенным способом об этом сказал в своём первом комментарии по этой теме.
            Ответить
    • Код абсолютно нормальный. Более того, код исключительно грамотный. Во-первых, использован правильный способ собирания числа из байтов (арифметика, а не пихание байтов в память) . Во-вторых, показано структура "магических констант", т.е. явно расписано `256 * 256`.

      Можно поспорить о том, не лучше ль было бы тут использовать сдвиги (возможно, лучше)... Но говнокодом тут и близко и не пахнет. Пахнет профессионализмом очень высокого уровня или по крайней мере зачатками такого профессионализма.
      Ответить
      • вы меня убедили. Просто такой способ перевода big/little endian меня, как бывшего ассемблерщика привел в недоумение
        Ответить
    • Намисал бы уже 0x100*0x100 или 0x10000, помоему так нагляднее
      Ответить
      • Ну а мне нагляднее всего сдвиги [и компилятору стараться не надо :)]. Кому-то нагляднее куча "256". Это всё лишь строго стилистика конкретного программиста. ;)
        Ответить
    • Компилятор это в сдвиги сам преобразует, так что отличный код.
      Ответить

    Добавить комментарий