Си диез / Говнокод #8231 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
namespace AppendStrinAtBegin
{
    class Program
    {
        static void ProcessDirectory(string path, string fileMask, Action<string> action)
        {
            Directory.EnumerateFiles(path, fileMask).ToList().ForEach(action);
            Directory.EnumerateDirectories(path).ToList().ForEach
                (
                    subDirectory => ProcessDirectory(subDirectory, fileMask, action)
                );
        }

        static void Main(string[] args)
        {
            Console.WriteLine("Path FileMask AppendedString");
            if (args.Length < 3)
                return;
            var appendedString = args.Skip(2).Aggregate((workingSentence, next) => workingSentence+ " " +next);
            ProcessDirectory(args[0], args[1], (file) => ProcessFile(file, appendedString));
            Console.WriteLine("Gun done");
        }

        static void ProcessFile(string file, string appendedStringAtBegin)
        {
            var fileLines = File.ReadAllLines(file, Encoding.GetEncoding(1251));
            var fileResulted = fileLines.ToList();
            fileResulted.Insert(0, appendedStringAtBegin);
            File.WriteAllLines(file, fileResulted, Encoding.GetEncoding(1251));
        }
    }
}

Запостил: ohlol ohlol, (Updated )

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

      • вы не можете определить что делает? в этом как раз и говнокод.
        Ответить
      • Я так понял, добавляет в начало всех файлов с заданной маской в заданном каталоге (рекурсивно) заданное предложение.
        Выглядит как небольшая тула на один раз (копирайт там добавить и т.п.)
        По-моему, код высокоуровневый и понятный, не такое уж и говно для одноразовой тулы.
        Ответить
        • Я здесь ничего не понимаю.

          >не такое уж и говно
          То есть говно есть? А в чем оно?
          Ответить
          • 1. AppendStrinAtBegin ещё бы Srin оставил(а)
            2. Завязка на конкретную кодировку
            3. Зачем было считывать строки и загружать их в память, разве нельзя просто дописать в начало файла?
            4. Обработка ошибок на высоте
            Ответить
            • >разве нельзя просто дописать в начало файла?
              И как вы себе это представляете?
              Ответить
              • Да, простого способа нет, манипуляция с позицией записи просто переписывает данные. Тогда вариант в топике вполне приемлем (C# не знаю, в java я бы сделал это более эффективно с помощью java.nio).
                Ответить
                  • Очень просто, открыть файл в режиме реверсной записи и передвинуть указатель на начало.
                    Ответить
                  • Вот, наговнявкал на Java примерчик http://pastebin.com/di1AT606 вроде даже работает. Для небольших файлов (а текстовые файлы обычно небольшие) должно быстро работать, для больших нужна дополнительная оптимизация.
                    Ответить
                    • Чем это лучше приведенного выше говнокода? Вся та же загрузка всего файла в память. И я так понимаю, используется побайтовое чтение, что должно быть ещё медленнее приведенного выше говнокода?

                      Спасибо, Роман.
                      Ответить
                      • В отличие от кода в топике, в моём примере содержимое файла никак не обрабатывается: не происходит сканирования и создания массива строк. Операции ввода/вывода через nio мапятся в нативные операции ввода/вывода, поэтому работать должно быстрее, чем код в топике (во всяком случае, для Java).
                        Собственно, нетрудно написать аналогичный вариант, использующий дополнительный временный файл, как предложено ниже.
                        Я бы ещё попробовал обойтись без дополнительного файла, читатя сразу по два буфера и записывая их с нужным смещением. Не уверен, что это сработает, но если сработает, то можно будет уменьшить вдвое число копирований.
                        Ответить
                        • >Я бы ещё попробовал обойтись без дополнительного файла, читатя сразу по два буфера и записывая их с нужным смещением.

                          Великолепнейшая идея, да. Это должно быть жёсткого диска головка-friendly.
                          Ответить
              • А создать бэкап, в оригинал поместить нужные данные и дописать из бэкапа?
                Ответить
                • создать новый файл, записать строку, дописать данные из исходного, исходный удалить, и переименовать (переместить) новый в старый
                  Ответить
                  • поддерживаю. этот код говно, тк памятью не правильно распоряжается. вот после такого и говорят, а не докупить ли нам ещё пару гектаров памяти, что-бы не тормозило...
                    а всего то нужно не писать говно и использовать правильный алгоритм.
                    Ответить
                    • я тут подумал...

                      нет на таких Б3-34 (и подобных ПМК) и Speccy.

                      посадить бы отдельно взятого говнокодера на указанные вещи на год или два, лишив доступа к современной технике, так гляди, и научится экономить шаги\такты и память. И вернемся к красоте, что фотожопы всякие будут весить 100-300К, а не 700М = )
                      Ответить
                      • Как по мне, дак это вовсе не экономия, а использование только того, что необходимо.
                        Но для этого необходимо понимать, что делает программа, а это уже сложнее, нежели писать лишь бы работала
                        Ответить
                      • >отожопы всякие будут весить 100-300К
                        Не будут. Сразу урежется большая часть функциональности. Я на это не подписывался.
                        Ответить
                • Не. Лези не даст той ленивости которая здесь нужна. Я говорю про ленивость загрузки элементов списка, а не о ленивости самого списка. То есть было бы очень не плохо, чтобы ReadAllхХх возвращал блок итераторов (энумератор), что позволило бы читать файл небольшим окошком под несколько строк. То есть не было бы таких в данном случае больших затрат памяти. Естественно все действия над этим энумератором также должны происходить лениво, а не энергично.
                  Ответить
                  • Чудило, в .NET4 есть метод File.ReadLines, который возвращает IEnumerable<string> и как раз таки является ленивым. Если кто-то этого не знает, чьи это проблемы?

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

                    школиё набигает 🙁
                    Ответить
                  • ohlol Позавчера # −4
                    Когда уже в C# добавят ленивый File.ReadAllхХх?

                    AnimeGovno-_- 12 часов назад # −1
                    Не. Лези не даст той ленивости которая здесь нужна. Я говорю про
                    Ответить
      • То есть, вы не смотрите, что выкладываете.
        Походу это и есть алехуй
        Ответить
        • > abatishchev
          >>>что делает? и в чем гавнокод?
          > ohlol
          >>>вы не можете определить что делает? в этом как раз и говнокод.

          95%
          Ответить
  • find . -type f $1 | xargs sed -i -e 1s//$2/

    Типа такого? (не проверял как работает).
    Ответить
      • Сдаётся мне, с xargs быстрее будет работать. Кстати, а разве ';' не нужно писать в конце?
        Ответить
        • Ничуть. С xargs, к тому же, нужно использовать нестандартные ключи, чтобы решить проблему пробелов в именах, а -exec переносим (правда, sed -i не очень переносим). Вместо ';' +.
          Ответить

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

Семь раз отмерь — один отрежь, guest!

    А не использовать ли нам bbcode?


    8