Comments 79
Мне кажется, этот комментарий на 100% можно развернуть в обратную сторону.
Раньше код "ехал" — выполнял что должен выполнять в 99.9999999% случаев и если где-то проскакивало 1000КБ — то было это при выводе на экран и в общем никого не колыхало (ничего не могло сломать).
Теперь это не только "ехать", но ещё и "шашечки", которые, как-бы, и не очень-то были нужны (для "ехать").
Более того, всегда можно вернуться к циклу.
Если знакомест было 3, а получили 4, то это могло ввести заблуждение 100 вместо 1000, например
Там же в строку потом единица измерения приписывается. Скорее потеряется буква "б", чем нолик из середины строки.
Скорее уж, "1000." вместо "1000.0". Впрочем, учитывая, что возвращается строка вместе с единицей измерения, выше риск, что затрётся последняя буква. Или, что хуже, потеряется нулевой символ при использовании буфера фиксированного размера.
Красивый бажный код подобен помоищному бажному коду, только с красотой.
Ну да, не хватает, например, кратких поясняющих комментариев, которые разобьют исправленный код на куда более легко воспринимаемые сегменты — и тем сделают его красивым. Но — он уже без бага, а исходная красота всё равно с оным.
Кстати, сам рассматриваемый в статье ответ на SO теперь тоже исправлен — и там вообще другая версия предложена, более грациозная:
public static String humanReadableByteCountSI(long bytes) {
return bytes < 1000L ? bytes + " B"
: bytes < 999_950L ? String.format("%.1f kB", bytes / 1e3)
: (bytes /= 1000) < 999_950L ? String.format("%.1f MB", bytes / 1e3)
: (bytes /= 1000) < 999_950L ? String.format("%.1f GB", bytes / 1e3)
: (bytes /= 1000) < 999_950L ? String.format("%.1f TB", bytes / 1e3)
: (bytes /= 1000) < 999_950L ? String.format("%.1f PB", bytes / 1e3)
: String.format("%.1f EB", bytes / 1e6);
}В статье же, таким образом, остался поучительный пример исправление красивого выглядящего правильным кода.
Оригинальный вариант с логарифмом ужасен, не настолько как в финале, но все же.
Предлагаю на собеседованиях если человек четко может дать определение логарифма — отсеивать, пусть математики вселенную изучают, а не код пишут.
Предлагаю на собеседованиях если человек четко может дать определение логарифма — отсеивать, пусть математики вселенную изучают, а не код пишут.А в биологи не брать тех, что знает число пи хотя бы до одного знака до запятой?
Вы про повреждения от попаданий снарядов и бомб?
Кстати, подобное исследование было бы действительно интересным — по какой именно математической формуле муравьи восстанавливают повреждённые муравейники — снова приводят их к круглому конусу, или же получается некая сглаженная пирамида с основанием в виде невыпуклого многоугольника?)
Справедливости ради, МАН — это школьная "академия". Для школьников такое "открытие" вполне простительно.
На мой взгляд, достаточно было бы просто 10^n заменить на 2^n.
Оригинальный вариант кода, пусть и неправильный, был красив. А после всех перипетий получилось помóище
Добро пожаловать в разработку библиотечного кода! Пишешь красивую реализацию чего-то, приходит 100500 человек, которые показывают тебе, что на вышедшем 100 лет назад железе, на Северном Полюсе, когда Луна в Водолее твой код не работает. И требуют исправлений. И ты исправляешь, потому что это же библиотека, должна работать везде.
Так, что ребята аккуратнее с публикацией опенсорса. Люди по дефолту
считают, что Вы теперь обязаны пожизненно сопровождать свой код бесплатно.
А как вы считаете, правильнее публиковать исправление очевидной и воспроизводимой (для тебя, на твоём железе) проблемы пулл-реквестом, или же иссуей + пулл-реквестом, фиксящим эту иссую и ссылающимся на эту иссую?
Я вот не так уж давно опубликовал 3 таких вот иссуи с фиксами в одну промышленную (!) библиотеку, но до сих пор ни один из пулл-реквестов не принят, а откомментирован разработчиками лишь одна из трёх иссуй, и ни один из реквестов.
Вам дан только пример для идеального случая, который показывает суть как надо решать
задачу. И то, что его всегда надо допиливать тем, что автор вынес за скобки
для простоты понимания сути.
Не надо его в лоб копировать в свои проекты.
Я бы сам написал код не лучше, чем первый вариант ответа, то есть тоже с багом. И уж точно хуже, чем текущий вариант, без ошибки. По сути использование кода со SO ничем не отличается использованием сторонних библиотек. Да, там могут быть ошибки, ну так они везде могут быть, даже в самом процессоре.
public static void main(String[] args) {
int byteSize = 123456789;
int mByteSize = byteSize >> 20;
System.out.println(mByteSize); // 117МБ
}
Лучше бы кучу IF'ов написал.
Его корректность легко доказать.
Я бы еще оттуда убрал вещественную арифметику, оставив только целые числа.
И убрал выход за пределы массива при нуле байт :)
Тут же всего лишь шесть шагов, зачем логарифмы считать?! Когда можно просто IF'ами сделать.
А если ещё и с середины сравнивать, то результат вообще за пару сравнений найти.
В самом популярном фрагменте кода за всю историю StackOverflow ошибка!
С удивлением узнал о таком коде. По тегу java вы легко найдёте гораздо более популярные вопросы и ответы. Похоже, автор имел в виду только свой популярный код.
В обсуждаемой заметке в разделе "Исследование по атрибуции" всё сказано — он увидел свой код на первом месте в исследовании, где был взят некий критерий популярности. Ссылки и картинка наличествуют.
Т.е. автор статьи ни разу ни чем не померил, а утверждает, что это самый популярный фрагмент?
Тенденция «Я Пастернака не читал, но осуждаю», набирает обороты на хабре. Ведь буквально первое же предложение в статье содержит ссылку на исследование, где и пришли к выводу о популярности данного фрагмента кода.
Данный текст я читал
Прямо-таки купили за 35 евро? Я вот не покупал, всего лишь зашел в References исследования и увидел там ссылку на данный ответ на Stackoverflow. Единственный ответ с кодом со Stackoverflow во всех References, что как бы намекает, ведь исследование называется «Usage and attribution of Stack Overflow code snippets in GitHub projects».
не заметил там указания, что данный фрагмент кода является самым популярным на GitHub
Во-первых, вы все путаете. Все ещё. Не «самый популярный на Github», а «самый копируемый сниппет со Stackoverflow, встречающийся на Github». То есть у данного вопроса самая большая область пересечения этих двух плоскостей: «код с ответа на SO» и «фрагмент кода на Github». Он популярен в своем первозданном виде. На Stackoverflow есть множество популярных ответов, с которых не́чего копировать, потому что они, внезапно, не оформлены, как ready-to-use сниппеты.
Но для вас этот факт как будто личное оскорбление.
На Stackoverflow есть множество популярных ответов, с которых не́чего копировать, потому что они, внезапно, не оформлены, как ready-to-use сниппеты.
Это проблема тех, кто копирует код. Захотят — скопируют, захотят — напишут сами. Не вижу проблемы в том, что код не отформатирован.
public static function humanReadableByteCount($bytes)
{
if ($bytes < 1024) {
return $bytes .' b';
}
if (($bytes /= 1024) < 1024) {
return round($bytes, 2) . ' KB';
}
if (($bytes /= 1024) < 1024) {
return round($bytes, 2) . ' MB';
}
if (($bytes /= 1024) < 1024) {
return round($bytes, 2) . ' GB';
}
return round($bytes/1024, 2) . ' TB';
}
(просто иллюстрация, не обязательно соответствует всем стандартам)
Читаем Хабр habr.com/ru/post/193256
Или на стандарт IEEE 1541/IEC 60027-2 можно не смотреть?
В предложенном мной варианте замена KB на KiB тривиальна.
Как и вынесение делителя в переменную типа $divisor = isSi? 1000: 1024;
Во всех операционных системах, во всём популярном софте в KB, MB, GB — множитель 1024 и никак иначе. Множитель 1000 стал использоваться там, где нет жёсткой привязки к степеням двойки. Ну и из соображений маркетинга.
Да, опытные люди знают про существование приставок Ki, Mi, Gi, но вот в обиходе они практически не используются. Люди привыкли, что в отношении количества информации эти приставки обозначают множитель 1024.
Кстати, вас не смущает использование фунтов, миль, баррелей? Эти единицы имеют разный размер в зависимости от контекста.
Чтобы исправить ситуацию, нужно, чтобы
Эти килобайты по основанию 1000 пришли от производителей дисков (до этого гениального решения продавать 1000000 байт вместо 1024*1024 и началась эта история, до того(по крайней мере из того что я видео) никто ни о каких 1000^n и не задумывался…
p.s. это как транСакции в финансах, когда гуманитарии добрались до ....
Напомнило о баге, который я репортил в Гитлаб, когда на коммит, сделанный 14 декабря, 15 марта пишется "2 months ago". Тоже небось со StackOverflow взяли пример, где автор не учел несколько пограничных случаев…
en.wikipedia.org/wiki/Computational_complexity_of_mathematical_operations
habr.com/ru/post/467933
А у меня вот такое получилось, правда на Python (ибо Java я варить не умею), но думаю в Java тоже есть "целочисленное деление" .
def humanReadableByteCount(size: int, si : bool) -> str:
unit = 1000 if si else 1024
exp = int(math.log(size)//math.log(unit))
pre = "{}{}".format(("", *("kMGTPE" if si else "KMGTPE"))[exp], ("" if si else "i"))
return "{:.1f} {}B".format(size//(unit**exp/10)/10, pre)Т.е. вместо деления сразу на 1000, сначала делим на 100, отбрасываем дробную часть, а потом делим ещё на 10. Таким образом при форматировании до 1 знака после запятой нет никаких округлений дробной части в большую сторону.
В самом популярном фрагменте кода за всю историю StackOverflow ошибка!