Vovox91, просить review можно. Для этого тег есть. Я просто акцентирую на том что код бывает не одородный. И тем более если он создан роботом, дизайнером или умым чятом то такой код не стоит просматривать человеку.
Во многих современных ЯП происходит плавный отказ от пре-процессора. Разработчики считают
что возможностей языка достаточно чтобы отработать такие кейсы. А споры о производительности
нивелируются если мы сравним сколько на самом деле потребляет прикладной код. И проверка
флага или переменной не будет столь значимой. Более значимо - работать в парадигме чистого
языка без предварительных аугментаций.
Василий Банников, а ну да. Согласен. На самом деле не сильно понятно что там автор считает легковесным.
Мы живем в эпоху когда мегабайты бесплаты. Их никто не считает. Мне кажется важнее
чтоб ОС была укомплектована всем необходимым.
Вот есть сообщество Генту-шников. У них вообще свой критерий легкого веса.
Игнат Соколов, поскольку хабр не занимется обучением я просто тебе дам подсказку.
Посчитай количество пар соседних символов которые одинаковы. Веди учет в перемнной.
aaaaaabbccccccccccdeeeeggggff
Вот здесь количество пар символов с будут 9 штук. Это значит 10 символов.
Если пара не получилась то сравнивай счетчик пар с максимумом. И запоминай символ
если было превышение макимума.
В конце максимум и последний учтенный символ и дадут тебе ответ.
Собственно семантика заложена в термине. Exception. Исключение. Что-то исключительное. Редкое.
Например мы работаем с файловой системой на сетевом диске и внезапно диск отъехал.
(Сеть мигнула). Не будем-же мы каждую файловую операцию снабжать кодом ошибки (как это
было в языке С ). Нам удобнее исходить из позитивного сценария.
Проверять capacity через Exception - я-бы не стал. Лучше бизнес логику закрепить тестами
и это загадочное капасити ловить на самом входе. Если это техническая валидация например
входных данных то она спокойно отбросит это кривое капасити в сторону безо всяких исключений.
NastyaNyushkova, да хранить это надо в системах версионного контроля.
GitHub как самый очевидный способ. Но это требует определенной культуры
разработки. И если вы раньше не работали то вам надо провести тренинги
для всех участников этого процесса. Поначалу бывает что людям не заходит.
Люди нервничают. Конфликтуют. Ищут простых путей. Делают копи-пасты
там где нужен merge и так далее. Вобщем эту моральную ломку вам надо
пройти.
Да если копировать россыпь мелких файлов через файловых протоколы типа NFS/CIFS то
можно и неделю просидеть с 1 терабайтом. Протокол избыточноый. Много метаинформации
передает.
Ntbackup как-то быстрее копирует - но кто его знает используют ли щас NTbackup или нет?
В Linux можно tar-ом соединять мелкие файлы в один блоб и как-то вот так повышать эффективность
использования сети для копирований.
