vladislavfetisov / split Goto Github PK

Про принятый стиль именования пакетов и переменных в Java можно почитать, например, здесь;

SplitLauncher. Выбранная библиотека позволяет сразу парсить аргументы в объекты класса File. Если хочется хранить именно пути, стоит посмотреть в сторону стандартных классов, предназначенных для работы с ними - Paths, Path;

SplitLauncher. Точно ли в методе launch нужно идти дальше после получения исключения?

SplitLauncher, Split. Часть некорректных ситуаций вроде отрицательных значений для опций, задающих правила деления файла, и полного отсутствия хотя бы одной из опций - пока не рассматриваются;

Про указание путей к ресурсам - добавила в файл с "Вопросами и ответами" информацию о том, как сделать проект переносимым для варианта с jar. Обращаю Ваше внимание, что прописанное в pom.xml для сборки архива сейчас выполнить нельзя, скачав Ваш проект с гит (поскольку отсутствует папка lib), а для архива, собираемого средствами Идеи - пока не указан главный файл, содержащий точку входа main, соответственно, архив не будет исполняемым;

Cut. Пока не очень понятно, что у Вас происходит с номером очередного файла. Почему переменная countFiles объявлена как static ? Что, если нам в программе потребуется создать несколько объектов класса Split, работающих с разными исходными? Номера выходных файлов для разных исходных файлов действительно должны зависеть друг от друга? Зачем нужно хранить массив имен, если очередное имя вроде как динамически можно получать по номеру (и, кстати, сделать так, чтобы количество имен не ограничивалось постфиксами от aa до zz здесь, вроде не сложно)?

Cut. Кажется, что-то пошло не так с областями видимости служебных методов вроде public String setOutputName(...), которые представляют из себя реализацию, а не интерфейс;

Cut. В интерфейсных методах вроде public String cutFile(...) в стандартных ситуациях стараются возвращать максимально структурированную информацию. Для представления состояний вида "вкл/ выкл", как правило, используются булевы величины. Это позволяет с меньшими затруднениями переиспользовать класс в случае необходимости;

Cut. Все ресурсы, в том числе, BufferedReader, после использования надо закрывать. Для того, чтобы это происходило автоматизированно в том числе, в случае возникновения исключений, имеет смысл посмотреть в сторону паттерна try-with-resources;

Cut. Как правило, в блоки try-catch все же стремятся оборачивать короткие блоки, для того, чтобы повысить анализируемость кода. Кроме этого, когда все, что Вы делаете при получении исключения, соответствует стандартной обработке (printStackTrace), лучше просто оставить throws на уровне сигнатуры метода;

Cut. Разделители в разных ОС будут разные. Здесь (все-таки) надо либо откатиться к варианту включения символов-разделителей в количество считываемых, либо учитывать разные возможности (на Ваш выбор). Отдельных пояснений требуют алгоритм fileSize (из него мы, вроде как, в текущей версии можем выйти с отрицательным размером), и ограничение if (countFiles > 100) break; в cutFile.