1. C++ / Говнокод #6481

    +167

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    String ExelCol(int col)
    {
      static const char c[] = { 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z' };
      String str;
      if( !col ) return str;
      while( true )
      {
        str.Insert( c[(col-1) % sizeof(c)], 1 );
        if( ! ((col-1) / sizeof(c)) ) break;
        col /= sizeof(c);
      }
      return str;
    }

    Запостил: ni3_inv, 26 Апреля 2011

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

    • > Exel
      Exel такой Exel
      Ответить
    • какое хитрое кодирование строки в число и назад.

      странно что вот таких говнокодов мало вижу, бо на практике это часто встречается: народ пытается строку в число как-нить запихнуть. или два числа в одно число. и с еще булевым флагом. или еще чего в том же духе. причина - эпик фэйл понимания структурного программирование и/или навыков моделирования данных.
      Ответить
      • Это перевод номера колонки Excel в ее буквенное наименование. Например, 27я колонка - AA.
        Ответить
      • Интересно, а сколько будет выполняться данный код с переменной col = 1000000(миллион)?
        Ответить
        • Как уже было сказано, данный код переводит число в 26-ричную систему счисления (с незначительнымы тонкостями). Алгоритм перевода - классический. Именно так это и делается. Придраться не к чему, кроме разве что использования 1-based индекса (как я уже писал).

          А дальше - сами смотрите. 1 миллион, говорите? В 26-ричной системе счисления это число должно записываться 5-ю знаками. Соответственно, ответ: код отработает за 5 итераций. И что тут "интересного"?
          Ответить
          • Интересно то, что я сейчас решаю как раз такую же задачу, только на Delphi.
            Ответить
          • TheCalligrapher
            Дайте асю (или жаббер). Разговор есть.
            Ответить
            • Да. Не хватает лички на говнокоде.
              Ответить
              • учитывая что сайт за два года(я тут с 2009) мало чем изменился её наверное уже никогда и не будет
                Ответить
              • А может сразу хабраблядствовать начнем?
                Ответить
                • блять унылый анон у тебя весь лексикон состоит из заимствований с лурка и местных мемов ты чем-нибудь другим удиви
                  Ответить
                • Введём карму и блекджек!
                  Ответить
    • эпично.
      Ответить
    • Придраться тут можно лишь к тому, что автор упрямо пытается работать с 1-based индексом столбца. Из-за этого упрямства приходится выписывать это кривое вычитание единицы во все формулы. Надо было сразу вычесть единицу из 'col' и работать далее с 0-based индексом. Получилось бы несколько элегантнее.

      А вот к использованию таблицы вместо вычисления целевого символа "формулой" придираться не стоит. Что лучше - вопрос неоднозначный. В данном случае я бы сказал что таблица даже лучше.
      Ответить
      • чем же использовать массив символов лучше?
        Ответить
        • Тем, что такое решение является произвольно настраиваемым, т.е. оно не накладывает на набор используемых символов никаких ограничений. Захочу - напишу какие угодно символы. (Хрен его знает, как там в каких-нибудь супер-интернациональных версиях Экселя. Может там где-нибудь используется непоследовательный набор символов). Если бы речь шла о таблице в 10К символов, то вписывать ее явно в код было бы глупо. Но 26 символов? Таблица однозначно предпочтительнее.

          Я бы в данном случае может быт даже вот так извратнулся
          const char *const c = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

          чисто ради компактности записи.
          Ответить
          • ...хотя для использования 'sizeof', разумеется, придется сделать
            static const char c[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

            и помнить, что 'sizeof' будет возвращать на 1 больше чем надо.
            Ответить
      • Я, признаться, наврал. Придраться тут есть к чему. В коде - бажина (все из-за тех же манипуляций с вычитанием единицы). Если уж вычитать единицу - то везде, и при переходе к следующей интерации надо было делать
        col = (col - 1) / sizeof(c);

        А то, что там сейчас написано начнет давать неправильный результат уже в конце каждого периода, начиная со второго. Для значения 'col = 52' этот код сгеренирует имя "BZ", вместо правильного "AZ".
        Ответить
        • А не правильней ли будет использовать для этого for ... do, а не while?
          Ответить
    • что-то вроде этого:

      int SIZE = 'Z' - 'A' + 1;
      string str;
      while(col > 0){
      str = char(((col - 1) % SIZE) + 'A') + str;
      col = (col - 1) / SIZE;
      }
      return str;
      Ответить
      • только для Ansi
        кодировкозависимо в общем
        Ответить
        • да, есть такое.
          код изначально для дельфи был, а там char задейайнен
          Ответить
      • > int SIZE = 'Z' - 'A' + 1;
        А сразу высчитать никак?
        Ответить
        • >А сразу высчитать никак?
          зачем? компилятор высчитает
          Ответить
          • *OMG*
            Быдлокодер детектед.
            Ответить
            • "говорящие" формулы времени компиляции всяко лучше, чем использовать результат из калькулятора, дружочек :)
              Ответить
              • Чем? Обоснуй.
                Ответить
                • Ну, если не понятно, то например по аналогии с 'Z'-'A': есть начальное значение (start), есть конечное (end), заданы константами. Где-то в коде требуется разница (len) между end и start. Неужели ты будешь каждый раз вычислять эту len на калькуляторе при изменении start и end?
                  Ответить
                  • Нет конечно, но в первом премере нужно вычислить значение только раз. Или я неправ? Тогда извините.
                    Ответить
                    • Пусть даже что и раз. Но компьютер-то железный, пусть он и считает. Тем более, что производительность кода от этого не страдает. Да и нагляднее это ('Z' - 'A' + 1) вместо магических "26".
                      Ответить
                      • А прокомментировать никак?
                        Ответить
                        • Лучший комментарий - это самодокументируемый код.
                          Ответить
                          • Но не в ущерб оптимизации.
                            Ответить
                            • Вот оптимизацию в большинстве случаев и приходится комментировать. Только говорить о ней рано. Как известно, преждевременная оптимизация - довольно большое зло.
                              Ответить
                              • Но это же очевидно!
                                Ответить
                                • последние 3-4 года стараюсь писать так чтоб код был понятен кому угодно, чтоб потом не доставали вопросами. правда не всегда получается:(
                                  Ответить
                                  • >правда не всегда получается:(
                                    надо писать на русском :)
                                    Ответить
                                  • угу. я тоже как-то пытался руководителю проекта обьяснить, что делает мой простенький код. Но вопрос "а нафига здесь цикл, когда можно 10 раз скопипастить" так и остался

                                    так что понятный код - еще не значит понятен ВСЕМ
                                    Ответить
                            • сложение и вычитание констант в состоянии оптимизировать даже допотопный компилятор.
                              здесь никак не повлияет на конечный результат, поэтому можно писать и так.
                              Ответить
                              • может быть говнокодера смущает производительность компилятора ;)
                                Ответить
                              • Парсер ПХП же тормозить будет из-за выражений!
                                Ответить
                                • пхп тормозит даже при длинных именах переменных!
                                  да, это просто лишний повод потормозить!
                                  Ответить
                                  • кстати - да
                                    например под виндой в вообще не запустится если в PATHTRANSLATED попали чужеродные символы
                                    Ответить
                                    • я заметил, но думал, что это проблема апача или модуля рерайта
                                      Ответить
                                      • железная логика, пхп плачет, что не может открыть файл, а виноват стабильный и матурный httpd :-)
                                        Ответить
                                • дык я про компилятор, а не про парсер.
                                  Ответить
        • чтобы магик-намберов не было
          Ответить
    • показать все, что скрытоПозвольте, господа, въебать вам всем по минусу ;-))
      Ответить

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