1. ActionScript / Говнокод #6098

    −103

    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
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    public static function trimExtraLineBreaks(string:String):String
    {
    	var trimmedString:String = string;
    
    	for(var i:int = 0; i < 20; i++)
    	{
    		trimmedString = trimmedString.replace(new RegExp("\r\r","g"),"\r");
    		trimmedString = trimmedString.replace(new RegExp("\r\n","g"),"\r");
    		trimmedString = trimmedString.replace(new RegExp("\n\n","g"),"\n");
    		trimmedString = trimmedString.replace(new RegExp("\n\r","g"),"\n");
    		trimmedString = trimmedString.replace(new RegExp("\n ","g"),"\n");
    		trimmedString = trimmedString.replace(new RegExp("\r ","g"),"\n");
    		trimmedString = trimmedString.replace(new RegExp(" \n","g"),"\n");
    		trimmedString = trimmedString.replace(new RegExp(" \r","g"),"\n");
    	}
    
    	return trimmedString;
    }

    Натолкнулся на просторах github'а во время поиска чего-то там... Ей богу сразу забыл, что искал.

    Запостил: fljot, 27 Марта 2011

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

    • супер. заплюсовал бы
      Ответить
    • Круглое носим, квадратное перекатываем?
      Ответить
      • Не, тут "пусть думает компьютер, он железный"
        В принципе, если бы бага обнаружилась в production-версии, я бы так и заткнул,
        а потом бы включал мозги и писал бы что-то более человеческое.
        Ответить
        • кроме регулярок инструментов нет? да и даже если регуляркой, то вполне можно обойтись одной
          Ответить
          • Вот как раз регулярка для этого — лучшее решение. Но автор ими пользоваться не умеет.
            Ответить
            • быть может, обойтись заменой или двумя просто строк?
              Ответить
              • Нет, придётся городить цикл. Это будет неэффективно, громоздко, говнокодно. Или писать конечный автомат — что тоже не очень умно в данном случае.

                Лучше воспользоваться готовым инструментом. Короче, понятнее, эфективнее. Ниже turdman привёл правильное решение.
                Ответить
        • Обычно когда баги обнаруживаются в продакшне, то версия в транке ушла уже на несколько ревизий вперед, и от попытки что-то по-быстрому исправить будет только хуже. Т.е. делать отдельный чек-аут для того, чтобы сделать одну правку, а потом еще думать как бы слить обе версии вместе - зачем это нужно.
          Записать багу и к следующей версии исправить. Если это какое-то очень важное ПО, то предупредить заказчика, но не пытаться править в продакшне, ну никогда это ничем хорошим не заканчивается :)
          Ответить
          • Это не оправдывает незнание регулярок
            Между грязным bugfix'ом и безграмотным грязным bugfix'ом все-таки есть разница

            return string.replace(new RegExp("[\t ]*[\r\n][\r\n\t ]*","g"),"\n");
            Ответить
            • а почему \t?
              Ответить
            • А я что-то говорил про регулярные выражения? Я говорил, и не постесняюсь повторится: по-быстрому поправить в продакшне = большая вероятность сломать больше, чем починить + остаться сверхурочно + создать себе дополнительную головную боль в то время, когда вы могли бы спокойно править баги к следующему релизу.
              Предположим, вы сейчас предложили правильный вариант. Но код, который был в продакшне зависел от неправильного. Предположим, что где-то дальше по коду кто-то делал
              if (string.indexOf("\t") > -1) callVeryImportantFunction();
              Вы поправили, все заработало. Вечером в бешенстве звонит заказчик и говорит, что сообщения об оплате перестали приходить вот уже как 5 часов. И вы становитесь угол, и повторяете мантру "я никогда не буду делать изменения в продакшене без предварительного тестирования".
              Ответить
              • Вот не надо придумывать проблемы там, где их нет. Исходный автор не понимал, что и зачем он делает, поэтому нагородил говнокод. Автор правильного решения понимает, поэтому написал правильно, да ещё и с учётом пожелания стоящего над плечом проджект-менеджера. А будь у него доступ ко всему коду, возможно написал бы ещё более адекватный код.
                Ответить
                • Пожалуйста обратите внимание, в третий раз, я ничего не говорил, и не говорю про правильность кода. Я говорю только и исключительно о том, что не нужно вносить правки в продакшне на скору руку, какими бы правильными они ни казались.
                  Ответить
    • напомните обезьянке о \t
      (но не говорите о комбинаторике)
      Ответить
      • а где в переносах строк вы нашли табуляцию? вы бы еще упомянули бип
        Ответить
        • пробел это тоже не совсем перенос :-Р
          ^G не буду, а к ночи помяну Soft CR из верхней половины таблицы
          Ответить

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