Как стать автором
Обновить

Комментарии 72

sleep() получает параметром миллисекунды, так что ещё на 1000 умножить надо.
спасибо за содержательный комментарий :)
NAME
sleep — Sleep for the specified number of seconds

SYNOPSIS
#include <unistd.h>

unsigned int sleep(unsigned int seconds);

DESCRIPTION
sleep() makes the calling thread sleep until seconds seconds have elapsed or a signal arrives which is not ignored.

RETURN VALUE
Zero if the requested time has elapsed, or the number of seconds left to sleep, if the call was interrupted by a signal handler.

CONFORMING TO
POSIX.1-2001.
Не хотелось бы быть занудами, но это спорное утверждение:) По разному бывает.
Хотя msdn.microsoft.com/en-us/library/ms686298%28VS.85%29.aspx (с большой буквы), тем не менее www.delorie.com/gnu/docs/glibc/libc_445.html (с маленькой).

Function: unsigned int sleep (unsigned int seconds)
The sleep function waits for seconds or until a signal is delivered, whichever happens first.
Вспомнилась связанная с этим история как Oracle Reports на линукс спортировали: vnaum.livejournal.com/9731.html
НЛО прилетело и опубликовало эту надпись здесь
«Ресурс по данному IP заблокирован по решению органов власти» Билайн.
Что хоть там?
#!/bin/bash
function f() {
    sleep "$1"
    echo "$1"
}
while [ -n "$1" ]
do
    f "$1" &
    shift
done
wait

./sleepsort.bash 5 3 6 3 6 3 1 4 7
Спасибо, давно так не ржал.
Вообще непонятно :(
Как написал кто-то в комментариях:
Это примерно как поразрядная или корзинная сортировка, но вместо «пространственного» массива используется «временной» массив
Если я правильно понял, программа получает число, спит это число секунд, потом сдвигает это число в конец массива.
т.е. в данном случае первым будет сдвинуто число 1, потом — три раза 3, потом 4, 5, 6, 6, 7
решение оригинальное, да. ))
Я так понял, что она запускает процесс, который спит это число секунд, потом печатает результат и останавливается. И проделывает это для всех чисел. В итоге каждое число будет напечатано в тот момент, которому оно равно.
Да, это ещё лучше.
Кому нужен массив ))
Получается она в нескольких экземплярах запускается? Или в никсах sleep не останавливает выполнение программы на N секунд?
Останавливает. Но после запуска f "$1" & она не ждёт завершения. Так что f запускается в нескольких экземплярах.
Круто!
Уж тогда Sleep(), а sleep вполне себе получает секунды.
+ Поддаётся автоматизированному тестированию
— Может быть протестирован, лишь как «чёрный ящик».

Ну, второе не является противоположностью первого. И вообще, разве есть код, который может быть протестирован только как «черный ящик»?

Статья слобоватенькая, и не особо информативная.
Может, если состоит из огромного скрипта без единой функции или если весь код в одной огромной функции.
Ну в этом случае «Белый ящик» — затруднителен, а автоматизированному функциональному тестированию ничего не мешает. Или нет?
Я вам один умный вещь скажу, только вы не обижайтесь пожалуйста. Тестирование есть проверка на соответствие спецификации. Если есть спецификация, любой код может быть протестирован как черный ящик. Тестировал (сам писал тесты, в команде естессно) JVM от Sun'a, javac, java API и никогда в их код не заглядывал. Ну разве что в некоторые стандартные классы из любопытства. Но у явы спецификации классные. Как результат — классные тесты и качественная реализация.

А вот когда спецификации нет, то тогда приходится лазить в код — именно за спецификацией. Только что там можно найти — говнофикацию разве что.
В случае отсутствия спецификаций, можно проявить телепатические свойства и на основе интуитивно понятного интерфейса программы, разработать спецификацию?

А на что я должен обижаться? То, что вы сказали как-то опровергает то, что я сказал?
Тут дело в частице «лишь».
Которая подразумевает, что юнит-тестирование не применимо.
Пример: программа, которая делает что угодно, используя лишь одну функцию. Юнит-тестирование попросту невозможно.

Да, пожалуй, надо было уточнить, что под автоматизированным подразумеваются прежде всего юнит-тесты.
Если претензия к этому — то принимаю и посыпаю голову пеплом. :)
А проблемы с юнит-тестированием — не показатель качества кода. Достаточно сколь угодно серьезного сайд -эффекта чтобы юнит тестирование было проблемным. А сайд-эффект, сам по себе, не показатель плохого кода.

Я знаю, что тестируемость — показатель качества кода, но формализовать это дело — не берусь.
Я тоже не берусь.
Просто высказываю соображения, которые, в зависимости от ситуации, могут быть важны — а могут быть и НЕ важны.
Об этом в посте говорится, но несколько вскользь.
И правда, зачем было выносить в комментарий то, что можно было написать буквально:
sleep(60 * 60 * 24);
Блин, ну понятное же дело — раз рантайм в этой функции слегка растянут во времени, значит надо бороться за сокращение времени компиляции хотя бы.
рефакторинг очевидно же.
Не знаю, не знаю. Лично я уже давно назубок помню, что 86400 — сутки, а 3600 — час.
Вы меня пугаете. ))
Оно просто запоминается — сначала восьмерка, потом две цифры, каждая из которых меньше предыдущей на 2. И два нуля.
Нет, я немного о другом.
Числа-то запоминать — в принципе дело полезное.
Телефоны там… адреса… явки, пароли… ))

Меня пугают слова программиста. который в контексте «индусского говнокода» спокойно так заявляет — ребята, я вот всегда готов написать нечто подобное и ничего страшного в этом не вижу.
Ну, во всяком случае Ваши слова прозвучали как-то так. ))

Очень надеюсь, что на самом деле (с) в виду имелось нечто иное ;)
Нет, серьезно. Более того, я бы сам так написал. Не считая конечно фееричность использования sleep в данном случае.

86400 с комментарием 60*60*24 отвечает требованиям микрооптимизиторов, и при этом обладает достаточной читаемостью.

Единственное исключение, пожалуй, что начиная с некоторого уровня абстракций, правильнее будет уже не 86400, а strtotime("+1 day").
Ну, понятно.
То есть Вы ратуете за использование этого числа, как зафиксированной данности.
А не за фееричное решение задачи с его помощью. :)
А что такое 768, помните?
Десятичное число вестимо.
256*3. Обычно используется, когда 512 мало, а 1024 много, но хочется «покруглее» в двоичном виде ))
Это наиболее близкий к правильному ответ.
Только 3 — еретическое число.

Правильный ответ:
768 это 512 + 256
Тогда, что такое 42?
Правильный ответ
32+8+2

365?
Правильный ответ
256+64+32+8+4+1

Точек в ширину на экране айпада в портретной ориентации, например.
Не поминай имени Э-л всуе
Высота монитора. При факторе 4:3 и ширине 1024. Соответственно, 3*256
В файлы с DNS зонами часто залезаете? :)
Проще написать 648000/Math.PI, чем вспомнить, как называется эта константа и в каком классе она определена. А при очередном рефакторинге заменить её по всему коду.
… если он, конечно, будет.
Не понял насчет утилитки и говнокода. Вы имеете в виду не слишком общо? В чем грязнота. Обычный линейный прикладной код без всяких шаблонов можно написать чистенько, что будет понятно, где мы что делаем.
Можно.
А можно написать грязно.
В том и дело, что в данном конкретном случае говнокод в принципе допустим.
Спасибо, я старался передать дух своего любимого писателя.
Насколько получилось — судить не мне. Сам я слишком самокритичен. ))
Отличная КДПВ! Даже в пост зашел. Но не осилил текст. Зато увидел сонную сортировку.
Спасибо — хотя Ваше третье предложение меня несколько расстраивает ))
Хочу обратить внимание, что одиночная разработка по сути не отличается от коммандной. Во-первых даже маленький скрипт бывает нужно доработать позже, придется вникать в свой же говнокод. Во-вторых любая более-менее крупная программа не умещается целиком в голове, все время нужно будет вовращаться к разным частям системы и анализировать. То есть тебя как бы много, если рассматривать разные моменты времени, так как ты каждый раз разный, с разным контекстом в голове.
Полностью согласен.
Более того — именно об этом я пишу в третьем и четвёртом примерах.

Просто разница в том, что, работая с собственным говнокодом, человек может не замечать всех связанных с этим проблем.
А в команде это становится очень хорошо видно, на контрастах. В хорошей команде, само собой.

Если в команде говнокодят чуть менее, чем все и каждый — то никто ничего не заметит.
Тоже вполне жизненная ситуация, к сожалению.
Очень хотелось бы дать почитать эту статью на английском своей команде.
плакать и жевать кактус
Как жизненно.
Спасибо, я очень старался, чтобы статья понравилась :)
Можно, конечно, написать и на английском.
Но получится несколько хуже.
Притом, что трудозатрат будет больше.
В общем — к сожалению, это для меня сейчас вряд ли возможно. :(
У меня есть такой эвристический критерий грязного/чистого кода:
Если после стандартного форматирования кода текст программы выглядит как ровные гладкие волны — то код скорее всего «чистый». Если же получились рваные неровные строчки с выбросами и провалами, то 99% это говнокод.
Странный критерий, откровенно говоря.
Поэтому критерий и эвристический — я не могу объяснить, почему это работает. И тем не менее красивый код выглядит красиво. И наоборот.
Надо будет поприглядываться :)
Хотя буквально сегодня довелось поразгребать вполне себе волнового говнеца )))
А «волны» определяются по левым или по правым краям строчек?
В основном по левым. Правый край гораздо менее показательный.
Тогда после стандартного форматирования левые края соседних строчек отличаются на 0 или 4 символа (язык C#, настройки — открывающаяся скобка на одной строчке с конструкцией, закрывающаяся — на отдельной строчке). И любая программа без goto выглядит, как те самые волны. Выбросам и провалам браться просто неоткуда.
Придя домой — не забудьте снять trollface ))
Спасибо, прочитал с большим удовольствием. Ваш текст напомнил мне о давнем, до сих пор не реализованном намереньи прочитать The Programmer's Stone. Правда, мне показалось, что последняя часть вашего рассмотрения («устремлённый») не вполне продолжает противопоставление «грязный-чистый»: например, неустремлённый программист (тот, который «не достигает вершины своего изначального потенциала» и работает строго по спецификациям в знакомой области) может производить очень чистый код. И наоборот, устремлённый супер-производительный «хакер» (в хорошем смысле :) ) может продвинуть сложный проект так, как никто другой, но при этом произведя не особо чистый код (например, натащив какого-нибудь «прогрессивного новья», интересного ему в данный момент, но не полезного проекту в долгосрочной перспективе); т.е. противопоставление неустремлённый / устремлённый не вполне коррелирует с противпоставлением производитель грязного / производитель чистого кода. Это неможко смазывает посыл сообщения, по-моему.
Спасибо за конструктивную критику. Действительно, этот момент у меня немного выбивается из общей канвы.
С другой стороны, текст писался, как обрамление бесплатным курсам чистого кода, которые я собираюсь проводить в ближайшее время.
И третья часть скорее объясняет — почему вообще я считаю, что такие курсы нужны. И почему я хочу вкладывать в это своё время и свой, пусть не самый богатый, опыт.
Очень рад, что текст сам по себе тоже может приносить пользу. Пожалуйста, реализуйте-таки своё намерение — от этого будет только польза и Вам лично, и окружающим :)
Ещё раз спасибо — за внимание, за понимание и за критику. :)
Спасибо, постараюсь — пишите, пожалуйста, ещё!

И ещё одно соображение про «чистый код». Один из планов этого понятия — просто аккуратно выглядящий на мелком и среднем уровнях код, например — использование одной и той же идиомы в сходных контекстах, в которых она полезна. Далее, хорошо, если в данной среде программирования есть «единственно верный» (всеми признаный) кодекс аккуратности (детальные coding guidelines, каталог идиом), но часто его нет, или есть несколько конкурирующих. В такой обстановке код, «чисто» написанный одним сильным программистом, другому сильному программисту покажется грязным (это может привести к частичной переделке, которая сделает код общего проекта локально чистым, но с разных точек зрения, и глобально грязным с любой точки зрения). Типичный способ преодоления этой трудности — установление специфичных для проекта coding guidelines, плюс (если есть соответствующий инструментарий) регулярная автоматизированная проверка исходного кода (статический анализ) на соответствие этим правилам.

Подытоживая: отсутствие coding guidelines создаёт неоправданный риск «неумышленного» загрязнения кода даже вполне ответственными «чисто» программирующими разработчиками — но он относительно легко устраним заимствованием / компиляцией такого документа (такая работа, по идее, не слишком обременительна для «устремлённых» :) ).
Совершенно согласен.
Поэтому в разных командах бывают свои, командные, гайдлайны.
Которые стараются от проекта к проекту не менять, чтобы, например, легче было перебрасывать людей из проекта в проект.
Вот при переходе из команды в команду (из компании в компанию) бывает, что приходится тратить некоторое время на подстраивание под принятый там стиль кодирования.

В то же время, гайдлайны эти если и различаются, то всё же их разнообразие вполне конечно и может быть легко изучено в краткие сроки.
Так что внутренние гайдлайны, хотя и принимаются вразнобой, но имеют гораздо более положительный эффект, чем добавляют трудностей. :)
Ищу на Хабре, где я с кем-то разговаривал на эти темы. Короче, навсяк, ссылка:
https://habrahabr.ru/post/301104/
(типа, не спам — перевод интересного текста)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории