Comments 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.
Хотя 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
UFO just landed and posted this here
«Ресурс по данному 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
решение оригинальное, да. ))
т.е. в данном случае первым будет сдвинуто число 1, потом — три раза 3, потом 4, 5, 6, 6, 7
решение оригинальное, да. ))
Круто!
Уж тогда Sleep(), а sleep вполне себе получает секунды.
+ Поддаётся автоматизированному тестированию
— Может быть протестирован, лишь как «чёрный ящик».
Ну, второе не является противоположностью первого. И вообще, разве есть код, который может быть протестирован только как «черный ящик»?
Статья слобоватенькая, и не особо информативная.
— Может быть протестирован, лишь как «чёрный ящик».
Ну, второе не является противоположностью первого. И вообще, разве есть код, который может быть протестирован только как «черный ящик»?
Статья слобоватенькая, и не особо информативная.
Может, если состоит из огромного скрипта без единой функции или если весь код в одной огромной функции.
Я вам один умный вещь скажу, только вы не обижайтесь пожалуйста. Тестирование есть проверка на соответствие спецификации. Если есть спецификация, любой код может быть протестирован как черный ящик. Тестировал (сам писал тесты, в команде естессно) JVM от Sun'a, javac, java API и никогда в их код не заглядывал. Ну разве что в некоторые стандартные классы из любопытства. Но у явы спецификации классные. Как результат — классные тесты и качественная реализация.
А вот когда спецификации нет, то тогда приходится лазить в код — именно за спецификацией. Только что там можно найти — говнофикацию разве что.
А вот когда спецификации нет, то тогда приходится лазить в код — именно за спецификацией. Только что там можно найти — говнофикацию разве что.
Тут дело в частице «лишь».
Которая подразумевает, что юнит-тестирование не применимо.
Пример: программа, которая делает что угодно, используя лишь одну функцию. Юнит-тестирование попросту невозможно.
Да, пожалуй, надо было уточнить, что под автоматизированным подразумеваются прежде всего юнит-тесты.
Если претензия к этому — то принимаю и посыпаю голову пеплом. :)
Которая подразумевает, что юнит-тестирование не применимо.
Пример: программа, которая делает что угодно, используя лишь одну функцию. Юнит-тестирование попросту невозможно.
Да, пожалуй, надо было уточнить, что под автоматизированным подразумеваются прежде всего юнит-тесты.
Если претензия к этому — то принимаю и посыпаю голову пеплом. :)
А проблемы с юнит-тестированием — не показатель качества кода. Достаточно сколь угодно серьезного сайд -эффекта чтобы юнит тестирование было проблемным. А сайд-эффект, сам по себе, не показатель плохого кода.
Я знаю, что тестируемость — показатель качества кода, но формализовать это дело — не берусь.
Я знаю, что тестируемость — показатель качества кода, но формализовать это дело — не берусь.
И правда, зачем было выносить в комментарий то, что можно было написать буквально:
sleep(60 * 60 * 24);
Индусская оптимизация.
Блин, ну понятное же дело — раз рантайм в этой функции слегка растянут во времени, значит надо бороться за сокращение времени компиляции хотя бы.
рефакторинг очевидно же.
Не знаю, не знаю. Лично я уже давно назубок помню, что 86400 — сутки, а 3600 — час.
Вы меня пугаете. ))
Оно просто запоминается — сначала восьмерка, потом две цифры, каждая из которых меньше предыдущей на 2. И два нуля.
Нет, я немного о другом.
Числа-то запоминать — в принципе дело полезное.
Телефоны там… адреса… явки, пароли… ))
Меня пугают слова программиста. который в контексте «индусского говнокода» спокойно так заявляет — ребята, я вот всегда готов написать нечто подобное и ничего страшного в этом не вижу.
Ну, во всяком случае Ваши слова прозвучали как-то так. ))
Очень надеюсь, что на самом деле (с) в виду имелось нечто иное ;)
Числа-то запоминать — в принципе дело полезное.
Телефоны там… адреса… явки, пароли… ))
Меня пугают слова программиста. который в контексте «индусского говнокода» спокойно так заявляет — ребята, я вот всегда готов написать нечто подобное и ничего страшного в этом не вижу.
Ну, во всяком случае Ваши слова прозвучали как-то так. ))
Очень надеюсь, что на самом деле (с) в виду имелось нечто иное ;)
Нет, серьезно. Более того, я бы сам так написал. Не считая конечно фееричность использования sleep в данном случае.
86400 с комментарием 60*60*24 отвечает требованиям микрооптимизиторов, и при этом обладает достаточной читаемостью.
Единственное исключение, пожалуй, что начиная с некоторого уровня абстракций, правильнее будет уже не 86400, а strtotime("+1 day").
86400 с комментарием 60*60*24 отвечает требованиям микрооптимизиторов, и при этом обладает достаточной читаемостью.
Единственное исключение, пожалуй, что начиная с некоторого уровня абстракций, правильнее будет уже не 86400, а strtotime("+1 day").
А что такое 768, помните?
— Петька, приборы!
— Двадцать!
— Что «двадцать»?!
— А что «приборы»?
— Двадцать!
— Что «двадцать»?!
— А что «приборы»?
Десятичное число вестимо.
256*3. Обычно используется, когда 512 мало, а 1024 много, но хочется «покруглее» в двоичном виде ))
Точек в ширину на экране айпада в портретной ориентации, например.
Высота монитора. При факторе 4:3 и ширине 1024. Соответственно, 3*256
В файлы с DNS зонами часто залезаете? :)
Проще написать 648000/Math.PI, чем вспомнить, как называется эта константа и в каком классе она определена. А при очередном рефакторинге заменить её по всему коду.
Не понял насчет утилитки и говнокода. Вы имеете в виду не слишком общо? В чем грязнота. Обычный линейный прикладной код без всяких шаблонов можно написать чистенько, что будет понятно, где мы что делаем.
Да вы Гоголь! ;)
Отличная КДПВ! Даже в пост зашел. Но не осилил текст. Зато увидел сонную сортировку.
UFO just landed and posted this here
Полностью согласен.
Более того — именно об этом я пишу в третьем и четвёртом примерах.
Просто разница в том, что, работая с собственным говнокодом, человек может не замечать всех связанных с этим проблем.
А в команде это становится очень хорошо видно, на контрастах. В хорошей команде, само собой.
Если в команде говнокодят чуть менее, чем все и каждый — то никто ничего не заметит.
Тоже вполне жизненная ситуация, к сожалению.
Более того — именно об этом я пишу в третьем и четвёртом примерах.
Просто разница в том, что, работая с собственным говнокодом, человек может не замечать всех связанных с этим проблем.
А в команде это становится очень хорошо видно, на контрастах. В хорошей команде, само собой.
Если в команде говнокодят чуть менее, чем все и каждый — то никто ничего не заметит.
Тоже вполне жизненная ситуация, к сожалению.
Очень хотелось бы дать почитать эту статью на английском своей команде.
плакать и жевать кактусКак жизненно.
У меня есть такой эвристический критерий грязного/чистого кода:
Если после стандартного форматирования кода текст программы выглядит как ровные гладкие волны — то код скорее всего «чистый». Если же получились рваные неровные строчки с выбросами и провалами, то 99% это говнокод.
Если после стандартного форматирования кода текст программы выглядит как ровные гладкие волны — то код скорее всего «чистый». Если же получились рваные неровные строчки с выбросами и провалами, то 99% это говнокод.
Странный критерий, откровенно говоря.
А «волны» определяются по левым или по правым краям строчек?
В основном по левым. Правый край гораздо менее показательный.
Тогда после стандартного форматирования левые края соседних строчек отличаются на 0 или 4 символа (язык C#, настройки — открывающаяся скобка на одной строчке с конструкцией, закрывающаяся — на отдельной строчке). И любая программа без goto выглядит, как те самые волны. Выбросам и провалам браться просто неоткуда.
Придя домой — не забудьте снять trollface ))
Спасибо, прочитал с большим удовольствием. Ваш текст напомнил мне о давнем, до сих пор не реализованном намереньи прочитать The Programmer's Stone. Правда, мне показалось, что последняя часть вашего рассмотрения («устремлённый») не вполне продолжает противопоставление «грязный-чистый»: например, неустремлённый программист (тот, который «не достигает вершины своего изначального потенциала» и работает строго по спецификациям в знакомой области) может производить очень чистый код. И наоборот, устремлённый супер-производительный «хакер» (в хорошем смысле :) ) может продвинуть сложный проект так, как никто другой, но при этом произведя не особо чистый код (например, натащив какого-нибудь «прогрессивного новья», интересного ему в данный момент, но не полезного проекту в долгосрочной перспективе); т.е. противопоставление неустремлённый / устремлённый не вполне коррелирует с противпоставлением производитель грязного / производитель чистого кода. Это неможко смазывает посыл сообщения, по-моему.
Спасибо за конструктивную критику. Действительно, этот момент у меня немного выбивается из общей канвы.
С другой стороны, текст писался, как обрамление бесплатным курсам чистого кода, которые я собираюсь проводить в ближайшее время.
И третья часть скорее объясняет — почему вообще я считаю, что такие курсы нужны. И почему я хочу вкладывать в это своё время и свой, пусть не самый богатый, опыт.
Очень рад, что текст сам по себе тоже может приносить пользу. Пожалуйста, реализуйте-таки своё намерение — от этого будет только польза и Вам лично, и окружающим :)
Ещё раз спасибо — за внимание, за понимание и за критику. :)
С другой стороны, текст писался, как обрамление бесплатным курсам чистого кода, которые я собираюсь проводить в ближайшее время.
И третья часть скорее объясняет — почему вообще я считаю, что такие курсы нужны. И почему я хочу вкладывать в это своё время и свой, пусть не самый богатый, опыт.
Очень рад, что текст сам по себе тоже может приносить пользу. Пожалуйста, реализуйте-таки своё намерение — от этого будет только польза и Вам лично, и окружающим :)
Ещё раз спасибо — за внимание, за понимание и за критику. :)
Спасибо, постараюсь — пишите, пожалуйста, ещё!
И ещё одно соображение про «чистый код». Один из планов этого понятия — просто аккуратно выглядящий на мелком и среднем уровнях код, например — использование одной и той же идиомы в сходных контекстах, в которых она полезна. Далее, хорошо, если в данной среде программирования есть «единственно верный» (всеми признаный) кодекс аккуратности (детальные coding guidelines, каталог идиом), но часто его нет, или есть несколько конкурирующих. В такой обстановке код, «чисто» написанный одним сильным программистом, другому сильному программисту покажется грязным (это может привести к частичной переделке, которая сделает код общего проекта локально чистым, но с разных точек зрения, и глобально грязным с любой точки зрения). Типичный способ преодоления этой трудности — установление специфичных для проекта coding guidelines, плюс (если есть соответствующий инструментарий) регулярная автоматизированная проверка исходного кода (статический анализ) на соответствие этим правилам.
Подытоживая: отсутствие coding guidelines создаёт неоправданный риск «неумышленного» загрязнения кода даже вполне ответственными «чисто» программирующими разработчиками — но он относительно легко устраним заимствованием / компиляцией такого документа (такая работа, по идее, не слишком обременительна для «устремлённых» :) ).
И ещё одно соображение про «чистый код». Один из планов этого понятия — просто аккуратно выглядящий на мелком и среднем уровнях код, например — использование одной и той же идиомы в сходных контекстах, в которых она полезна. Далее, хорошо, если в данной среде программирования есть «единственно верный» (всеми признаный) кодекс аккуратности (детальные coding guidelines, каталог идиом), но часто его нет, или есть несколько конкурирующих. В такой обстановке код, «чисто» написанный одним сильным программистом, другому сильному программисту покажется грязным (это может привести к частичной переделке, которая сделает код общего проекта локально чистым, но с разных точек зрения, и глобально грязным с любой точки зрения). Типичный способ преодоления этой трудности — установление специфичных для проекта coding guidelines, плюс (если есть соответствующий инструментарий) регулярная автоматизированная проверка исходного кода (статический анализ) на соответствие этим правилам.
Подытоживая: отсутствие coding guidelines создаёт неоправданный риск «неумышленного» загрязнения кода даже вполне ответственными «чисто» программирующими разработчиками — но он относительно легко устраним заимствованием / компиляцией такого документа (такая работа, по идее, не слишком обременительна для «устремлённых» :) ).
Совершенно согласен.
Поэтому в разных командах бывают свои, командные, гайдлайны.
Которые стараются от проекта к проекту не менять, чтобы, например, легче было перебрасывать людей из проекта в проект.
Вот при переходе из команды в команду (из компании в компанию) бывает, что приходится тратить некоторое время на подстраивание под принятый там стиль кодирования.
В то же время, гайдлайны эти если и различаются, то всё же их разнообразие вполне конечно и может быть легко изучено в краткие сроки.
Так что внутренние гайдлайны, хотя и принимаются вразнобой, но имеют гораздо более положительный эффект, чем добавляют трудностей. :)
Поэтому в разных командах бывают свои, командные, гайдлайны.
Которые стараются от проекта к проекту не менять, чтобы, например, легче было перебрасывать людей из проекта в проект.
Вот при переходе из команды в команду (из компании в компанию) бывает, что приходится тратить некоторое время на подстраивание под принятый там стиль кодирования.
В то же время, гайдлайны эти если и различаются, то всё же их разнообразие вполне конечно и может быть легко изучено в краткие сроки.
Так что внутренние гайдлайны, хотя и принимаются вразнобой, но имеют гораздо более положительный эффект, чем добавляют трудностей. :)
Sign up to leave a comment.
Грязный, чистый, устремлённый