Откуда пробел?

← →
OW © (2011-11-29 16:48) [0]

function TfrmDVBT.MyDateToStr(dt: TDateTime; format: string): string; var fs: TFormatSettings; begin fs.LongTimeFormat := format; Result := DateTimeToStr(Now, fs); end; mmoDebug.Lines.Add ("=" + MyDateToStr(Now,"dd-mm-yyyy") + "="); mmoDebug.Lines.Add ("=" + MyDateToStr(Now,"hh-mm-ss dd-mm-yyyy") + "=" );

= 29-11-2011=
= 16-46-38 29-11-2011=

=[пробел]29-11-2011=
=[пробел]16-46-38 29-11-2011=

← →
Компромисс (2011-11-29 16:59) [1]

Всегда надо точное место ошибки локализовывать.
Например, проверить результат DateTimeToStr(Now, fs).

← →
sniknik © (2011-11-29 17:00) [2]

недо инициализированная переменная, + параметр dt не используется.

так?
function TfrmDVBT.MyDateToStr(dt: TDateTime; format: string): string; begin DateTimeToString(Result, format, dt); end;

← →
Медвежонок Пятачок © (2011-11-29 17:07) [3]

//fs.LongTimeFormat := format;

fs.ShortTimeFormat := format;

← →
OW © (2011-11-29 17:08) [4]

> sniknik © (29.11.11 17:00) [2]
> недо инициализированная переменная, + параметр dt не используется.

забыл убрать dt .
да и так можно обойти
function TfrmDVBT.MyDateToStr(dt: TDateTime; format: string): string;
begin
Result := FormatDateTime(format, dt);
end;
или сразу, просто там еще поля могут передаваться, короче сложнее несколько :)
просто интересно стало, почему пробел(!?)
наверное, от недоинициализированности

всем спасибо.

← →
Компромисс (2011-11-29 17:24) [5]

> function TfrmDVBT.MyDateToStr(dt: TDateTime; format: string):
> string;
> begin
> Result := FormatDateTime(format, dt);
> end;

За подобные функции (если они такими создавались, а не эволюционировали) надо наказывать.

← →
OW © (2011-11-29 17:32) [6]

>> Компромисс (29.11.11 17:24) [5]
согласен
но это упрощение, говорю же

← →
sniknik © (2011-11-29 17:38) [7]

> За подобные функции (если они такими создавались, а не эволюционировали) надо наказывать.
ты прикинь, реализация в VCL сама требует, вопиет можно сказать, о наказании... :)

function FormatDateTime(const Format: string; DateTime: TDateTime): string; begin DateTimeToString(Result, Format, DateTime); end;

← →
Компромисс (2011-11-29 17:47) [8]

sniknik © (29.11.11 17:38) [7]

Возможно, именно поэтому Borland была вынуждена продать Delphi :)

← →
картман © (2011-11-29 17:49) [9]

> sniknik © (29.11.11 17:38) [7]

VCL: а почему она всегда за эталон?

← →
Компромисс (2011-11-29 17:50) [10]

sniknik © (29.11.11 17:38) [7]

Хотя я бы сказал, что это попытка исправить кривой дизайн. Надо было сразу сделать DateTimeToString функцией, которая не только параметр меняет, но и возвращает его же в качестве результата.

← →
Kerk © (2011-11-29 18:02) [11]

> картман © (29.11.11 17:49) [9]
>
> > sniknik © (29.11.11 17:38) [7]
>
> VCL: а почему она всегда за эталон?

Потому что VCL написана лучше, чем код в твоем проекте. Причем ни тебя, ни твой проект я не видел. Просто имею 99% вероятность угадать :)

← →
Компромисс (2011-11-29 18:04) [12]

Kerk © (29.11.11 18:02) [11]

Плохая "логика".

← →
Kerk © (2011-11-29 18:08) [13]

> Компромисс (29.11.11 18:04) [12]

Почему же плохая? Или ты написал уже что-то более читаемое, чем VCL? Теоретизировать каждый горазд, это я и сам могу. А как этот каждый попадет в большой проект, то сразу "ой".

← →
Компромисс (2011-11-29 18:12) [14]

> Почему же плохая? Или ты написал уже что-то более читаемое,
> чем VCL? Теоретизировать каждый горазд, это я и сам могу.
> А как этот каждый попадет в большой проект, то сразу "ой".
>

Плохая она в том, что надо стремиться не к лучшему из имеющихся, а к идеальному.

← →
картман © (2011-11-29 18:16) [15]

> Kerk © (29.11.11 18:02) [11]

> Просто имею 99% вероятность угадать :)

Вот! Я именно о не о 100% ))
и не только: неужто они весь код могли прошерстить, да вышлифовать?

← →
sniknik © (2011-11-29 23:56) [16]

> надо стремиться не к лучшему из имеющихся, а к идеальному.
идеального не бывает. это только образ в твоей голове. за такой легкой, неуловимой дымкой. но сними с образа покровы, рассмотри внимательней, и увидишь то еще убожество...

p.s. вот так и вырастают "неуклюжие романтики", говорят о прекрасном, а на деле и "просто красивого" сделать не могут. ;)

← →
sniknik © (2011-11-29 23:58) [17]

> Надо было сразу сделать DateTimeToString функцией
на DateTimeToString VCL не кончается... там есть куча примеров "прямого дизайна", где из функцию в функцию.

← →
Германн © (2011-11-30 01:28) [18]

> идеального не бывает.

У некоторых бывает, но если я уточню у кого, то ветка перейдёт на политику. Поэтому молчу, надеюсь "тот самый некоторый" сам поймёт. :)

← →
sniknik © (2011-11-30 08:07) [19]

> У некоторых бывает,
никогда не приходилось возвращаться к своему же старому коду? когда вроде и претензий нет, работает, хорошо, надежно... но. вот тут можно улучшить, вот тут упростить. тут ускорить, и вообще все как то "не так".
а ведь если бы было реально идеальным (близким к нему) то никакие переделки были бы не нужны. просто "образ в голове" меняется, с опытом, знаниями. то что тогда казалось самое "оно!" сейчас уже "совсем не то".
если у этого твоего "некоторого" не так, значит он не прогрессирует, остановился в развитии.

← →
Компромисс (2011-11-30 10:51) [20]

sniknik © (29.11.11 23:56) [16]

В данном примере я стремлюсь к тому, чтобы у меня вообще не было багов и кривых функций. Даже если у Вашего "эталона" VCL они есть.

← →
Компромисс (2011-11-30 10:54) [21]

> на DateTimeToString VCL не кончается... там есть куча примеров
> "прямого дизайна", где из функцию в функцию.

Каждый случай надо рассматривать отдельно. Я не вижу ничего плохого в коде вида

function f1(a, b: String):String; begin Result = f2(a,b, 12); end;

Если чо :)

← →
Компромисс (2011-11-30 10:55) [22]

sniknik © (30.11.11 08:07) [19]

Вот именно. Чего спорите, вообще непонятно. Речь не о том, чтобы улучшать код до идеального, а о том, чтобы сразу стараться писать идеально. Вспомним, с чего всё началось:

> За подобные функции (если они такими создавались, а не эволюционировали)
> надо наказывать.

← →
sniknik © (2011-11-30 12:03) [23]

> у меня вообще не было багов и кривых функций.
а причем тут идеал?... крепкий, не кривой кувшин не значит "идеальный", а код значит? странно.

> Чего спорите, вообще непонятно
я ????

> Вспомним, с чего всё началось:
>> За подобные функции (если они такими создавались, а не эволюционировали)
>> надо наказывать.
т.е. наказывать нужно в любом случае... т.к. все меняется, представления об идеалах тоже... сегодня наказывать за то, что не близко к завтрашнему "идеалу", завтра к вчерашнему. и всегда есть сразу созданное, а не эволюционировавшее.

← →
Компромисс (2011-11-30 12:30) [24]

> я ????
>

Ну не я же первым на личные выпады перешел.

> т.е. наказывать нужно в любом случае... т.к. все меняется,
> представления об идеалах тоже... сегодня наказывать за
> то, что не близко к завтрашнему "идеалу", завтра к вчерашнему.
> и всегда есть сразу созданное, а не эволюционировавшее.
>

Конечно, сразу наказывать не стоит, особенно если код написан студентом. В первый раз следует объяснить, что и почему. Но если после объяснения продолжается "быдлокодинг", то необходимо наказывать, а лучше уволить. Программист, не способный к обучению, нам не нужен. Переделывать за ним код может занять больше времени, чем написать самому.

Кстати, Ваш "подход" оправдывает любой код. Только вот подход неверный - некоторый код сразу плох и не только никогда не станет идеальным, но даже не перестанет быть плохим.

← →
Kerk © (2011-11-30 12:33) [25]

> Компромисс (30.11.11 10:51) [20]
>
> sniknik © (29.11.11 23:56) [16]
>
> В данном примере я стремлюсь к тому, чтобы у меня вообще
> не было багов и кривых функций.

Ну и в результате-то что? Получается?

Я тебя уже спрашивал, написал ли ты уже что-то более читаемое, чем VCL. Ответа не последовало, так что видимо, ответ -- нет. Так что старайся, старайся.

← →
Kerk © (2011-11-30 12:40) [26]

Тут видишь ли в чем дело, дай любому студенту почитать Макконнелла и ещё каких-нибудь пару книжек и он тебе аргументировано объяснит, почему то, что ты пишешь -- жуткий быдлокод. Может быть даже подумает, что тебя нужно уволить. А напишет ли он что-то лучше тебя? Ну не факт, не факт.

Вырвать кусочек кода и начать его критиковать -- это очень легко. Но смысла в этом нет никакого.

← →
Компромисс (2011-11-30 12:47) [27]

> Я тебя уже спрашивал, написал ли ты уже что-то более читаемое,
> чем VCL. Ответа не последовало, так что видимо, ответ -
> - нет. Так что старайся, старайся.

Извини, я не понял, что ты меня спрашивал. Да, я написал несколько своих framework, правда, на Java, а не Delphi. Есть и библиотеки своих компонентов на Flex. Показать не могу, конечно :)

Только ведь это не важно. Как там у Бернарда Шоу - "Чтобы оценить вкус яичницы, необязательно нести яйца"? Если я вижу недостаток в коде, я на него указываю. Если в моем коде кто-то видит недостатки, пусть тоже указывает. А как иначе???

← →
Компромисс (2011-11-30 12:50) [28]

> Вырвать кусочек кода и начать его критиковать -- это очень
> легко. Но смысла в этом нет никакого.

А я вот вижу смысл. Из мелких деталей складывается общая картина. Здесь как-то проскакивала ссылка на статью, где американец рассказывал, как он проводит интервьюирование программистов. Дает простое задание и смотрит на то, как именно и на какой скорости ее решают. У хорошего программиста хороший код пишется на автомате, вплоть до именования аргументов методов.

А, бесполезный разговор. Просто выложи свой код, строчек 500-1000 хотя бы. И мы будем его как пример хорошего кода вместо VCL показывать.

> Как там у Бернарда Шоу - "Чтобы оценить вкус яичницы, необязательно
> нести яйца"?

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

← →
Компромисс (2011-11-30 13:16) [30]

> Вот это вот совсем ни к чему. Если продолжать аналогию,
> то ты критикуешь яичницу на форуме поваров. Так почему бы
> тебя не попросить приготовить свою яичницу, показав всем
> пример?

Я приготовил яичницу еще в Компромисс (29.11.11 17:50) [10]

Могу еще привести пример. Методы по умолчанию должны иметь модификатор protected, а не private. Чтобы потом не пришлось костыли искать. То есть должна быть причина, почему разработчик использовал именно private. Если причины нет, то следовало использовать protected.

> Методы по умолчанию должны иметь модификатор protected,
> а не private. Чтобы потом не пришлось костыли искать. То
> есть должна быть причина, почему разработчик использовал
> именно private. Если причины нет, то следовало использовать
> protected

"Вы, сударь, ерунду говорите. И хуже всего то, что говорите безапеляционно и уверенно"

> Могу еще привести пример.
твои примеры не "яичница", скорее набор предрассудков.

← →
Компромисс (2011-11-30 14:00) [33]

Игорь Шевченко © (30.11.11 13:49) [31]

Могу объяснить. По умолчанию, следует считать, что когда-то кто-то захочет написать наследника, в котором захочет изменить указанный метод.

> Если я вижу недостаток в коде, я на него указываю.
первый "недостаток" на который указал это просто стиль написания. удобство для каждого конкретно... ну к примеру функцию со своим значимым названием использовать, а не стандартную, + может пару тройку аргументов убрать, писать меньше, и т.д.
что такого то?
наказать только потому, что ТЕБЕ непонятно зачем, потому, что не соответствует ТВОИМ идеалам?
а ты вернись к ним лет так через 5. перепроверь.

← →
Компромисс (2011-11-30 14:04) [35]

> твои примеры не "яичница", скорее набор предрассудков.

Моя яичница в [10]. К ней есть претензии?

← →
Компромисс (2011-11-30 14:09) [36]

sniknik © (30.11.11 14:04) [34]

Согласен, смысл есть. Чтобы легко можно было поменять реализацию метода, а не менять вызовы стандартного метода по всей программе. Но не в данном случае с format date :)
myAssignFile
myWrite
myCloseFile

Жалко, myFor не написать :)

← →
Компромисс (2011-11-30 14:13) [37]

Игорь Шевченко © (30.11.11 13:49) [31]

Кстати, в той же java модификатор по умолчанию позволяет даже больше, чем protected. Так что не только я так думаю, получается :)

Компромисс (30.11.11 14:00) [33]

> Могу объяснить. По умолчанию, следует считать, что когда-
> то кто-то захочет написать наследника, в котором захочет
> изменить указанный метод.

А вот тот же МакКоннел считает, что "интерфейс класса должен сообщать как можно о внутренней работе класса." (стр. 89)
И Фаулер считает, что "делайте каждый метод как можно более закрытым" (стр. 306)

Я склонен их опыту доверять больше. Более того, я даже больше склонен доверять своему опыту, который показывает, что по мере развития классов часть методов может оказаться неиспользуемыми. В случае [strict]private компилятор скажет, что метод не используется, а в остальных случаях у него этой информации нету.

← →
Компромисс (2011-11-30 14:34) [39]

> А вот тот же МакКоннел считает, что "интерфейс класса должен
> сообщать как можно о внутренней работе класса." (стр. 89)
> И Фаулер считает, что "делайте каждый метод как можно более
> закрытым" (стр. 306)

Я тоже с ними согласен. Потому что они говорят о случае, когда наследников нет и не будет. Иначе не было бы фразы "интерфейс класса должен сообщать как можно о внутренней работе класса.". Я бы еще рекомендовал добавлять final модификатор к самому классу, чтобы никто наследников и не пытался писать.

> Потому что они говорят о случае, когда наследников нет и
> не будет

не говорят

Откуда пробел? Найти похожие ветки