Ситуация: Функция/метод создает файл, пишет в него некий заголовок и передает его дескриптор или связанный с ним поток другим функциям/методам, которые тоже иногда пишут кое-что в этот файл. А иногда не пишут.

Запрос пользователя (change request): Если никакой информации кроме заголовка в файле нет, нечего и файл создавать.

Мнение программиста: Если пустой файл никому не мешает, нечего и избыточную логику в программе городить.

А вы что скажете?

Здравствуйте, igna, Вы писали:

I>А вы что скажете?

Смотря как часто это происходит.

I>Ситуация: Функция/метод создает файл, пишет в него некий заголовок и передает его дескриптор или связанный с ним поток другим функциям/методам, которые тоже иногда пишут кое-что в этот файл. А иногда не пишут.

I>Запрос пользователя (change request): Если никакой информации кроме заголовка в файле нет, нечего и файл создавать.

I>Мнение программиста: Если пустой файл никому не мешает, нечего и избыточную логику в программе городить.

I>А вы что скажете?

попробуйте создать пустой exe-файл
попробуйте создать пустой C++ — файл

с другой стороны, попробуйте создать пустой mp3 или perl-скрипт

так что, как решите, так и будет.

Здравствуйте, igna, Вы писали:

I>А вы что скажете?
Чтобы не было лени по реализации так названной программистом "избыточной логики", в файл должны писать не все, кому не лень, а только один специальный класс вроде логгера.

Здравствуйте, igna, Вы писали:

I>Ситуация: Функция/метод создает файл, пишет в него некий заголовок и передает его дескриптор или связанный с ним поток другим функциям/методам, которые тоже иногда пишут кое-что в этот файл. А иногда не пишут.

I>Запрос пользователя (change request): Если никакой информации кроме заголовка в файле нет, нечего и файл создавать.

I>Мнение программиста: Если пустой файл никому не мешает, нечего и избыточную логику в программе городить.

I>А вы что скажете?

Заказчик всегда прав.

Здравствуйте, eao197, Вы писали:

E>Заказчик всегда прав.

Он не заказчик, он пользователь.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, eao197, Вы писали:

E>>Заказчик всегда прав.

I>Он не заказчик, он пользователь.

Боюсь, эту тонкую разницу сможет различить только программист, но не заказчик с пользователем.

Здравствуйте, rsn81, Вы писали:

R>Чтобы не было лени по реализации так названной программистом "избыточной логики", в файл должны писать не все, кому не лень, а только один специальный класс вроде логгера.

А чтобы не было лени по реализации специального класса?

История такова:

1) Сначала (несколько лет тому назад) программа выводила некую последовательность строк в файл. В случае пустой последовательности файл не создавался. Реализовать это было просто, достаточно было одного if.

2) Потом добавили вывод еще одной последовательности строк в тот же файл. Сделано было так: в случае непустой второй последовательности файл открывался повторно на добавление.

3) Затем формат файла переделали в XML, соответственно понадобился заголовок и наоборот footer. Заголовок писали непосредственно перед выводом первой последовательности, footer — непосредственно после вывода второй. Таким образом ввели 2 бага, поскольку заголовок не выводился, если пустой была первая последовательность, footer — если вторая.

4) Через некоторое время второй баг был обнаружен и его в спешке пофиксили добавлением вывода footer-а непосредственно после вывода первой последовательности, что привело к появлению третьего бага, поскольку footer в некоторых случаях выводился дважды.

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

Понимаю, что решение зависит от конкретного случая, но хотелось бы, чтобы кто-нибудь написал бестселлер вроде "Не приставайте к программисту с ненужными пожеланиями". (Хотя возможно в данном случае это была инициатива программиста, тогда книжка другая нужна.)

Здравствуйте, eao197, Вы писали:

E>Боюсь, эту тонкую разницу сможет различить только программист, но не заказчик с пользователем.

Стоят заказчик с пользователем напротив друг друга и не могут различить кто есть кто? Наверное приемка программы успешно прошла.

Здравствуйте, igna, Вы писали:

I>3) Затем формат файла переделали в XML, соответственно понадобился заголовок и наоборот footer. Заголовок писали непосредственно перед выводом первой последовательности, footer — непосредственно после вывода второй. Таким образом ввели 2 бага, поскольку заголовок не выводился, если пустой была первая последовательность, footer — если вторая.

тут однозначно ошибка проектирования, XML для добавления очень неудобен

по поводу незаписи пустого файла, логично было б в нужный момент времени
проверять, пустой ли файл и, если пустой, удалять его

Здравствуйте, VsevolodC, Вы писали:

VC>по поводу незаписи пустого файла, логично было б в нужный момент времени
VC>проверять, пустой ли файл и, если пустой, удалять его

Он будет не совсем пустой, там заголовок.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, VsevolodC, Вы писали:

VC>>по поводу незаписи пустого файла, логично было б в нужный момент времени
VC>>проверять, пустой ли файл и, если пустой, удалять его

I>Он будет не совсем пустой, там заголовок.

значит, файл с заголовком без данных

Здравствуйте, VsevolodC, Вы писали:

VC>значит, файл с заголовком без данных

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

Здравствуйте, igna, Вы писали:

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

если заголовок неизменен, то это длина файла = длине заголовка.

Но имхо, лучше всего сделать спец класс, в который тупо пихать данные. А тот уже сам решает надо или нет создавать файл.

А если это xml то можно и вообще использовать XmlDocument, записывать данные в него, а потом все сразу сохранять. Или не сохранять ничего, если данные так и не вложили.


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

Здравствуйте, eao197, Вы писали:

E>Боюсь, эту тонкую разницу сможет различить только программист, но не заказчик с пользователем.

Заказчик платит деньги, пользователь использует программу. Могут быть в одном лице, могут быть в разных.

По любому — пользователь говорит, что он хочет, программист говорит цену. Заказчик либо платит, либо объясняет пользователю, что ему лучше жить без этой фичи Даже если заказчик и пользователь одно лицо

Здравствуйте, fmiracle, Вы писали:

F>По любому — пользователь говорит, что он хочет, программист говорит цену. Заказчик либо платит, либо объясняет пользователю, что ему лучше жить без этой фичи Даже если заказчик и пользователь одно лицо

А если программист и пользователь в некотором смысле одно лицо? Этот файл читается другими программами.

Здравствуйте, fmiracle, Вы писали:

F>Здравствуйте, eao197, Вы писали:

E>>Боюсь, эту тонкую разницу сможет различить только программист, но не заказчик с пользователем.

F>Заказчик платит деньги, пользователь использует программу. Могут быть в одном лице, могут быть в разных.

F>По любому — пользователь говорит, что он хочет, программист говорит цену. Заказчик либо платит, либо объясняет пользователю, что ему лучше жить без этой фичи Даже если заказчик и пользователь одно лицо

Показательно, что начинают доказывать разницу между пользователем и заказчиком программисты.

Между тем ситуация очень ясна: пользователь программы говорит -- мне не нужны пустые файлы. Значит, программист должен рассматривать это как недостаток своего продукта. Недостатки нужно устранять, поскольку продукт с недостатками может привести к потере заказчика. А если (в пределе) программист теряет работу потому что заказчик отказался от продукта из-за неустраненных недостатков, то, censored, ЕСТЬ ЛИ РАЗНИЦА В ТОМ, УКАЗАЛ ЛИ НА НЕДОСТАТОК ПОЛЬЗОВАТЕЛЬ ИЛИ ЗАКАЗЧИК?

Здравствуйте, igna, Вы писали:

I>А если программист и пользователь в некотором смысле одно лицо? Этот файл читается другими программами.

Ну так соберитесь все втроём и договоритесь

Здравствуйте, igna, Вы писали:

I>Здравствуйте, VsevolodC, Вы писали:

VC>>значит, файл с заголовком без данных

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

может и сложнее, на этот момент
а если еще в 5-6 местах в этот файл будут делаться записи?
если есть проблема, ее надо локализовать, это уменьшит число потенциальных багов

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

если же, как вы утверждаете, этот файл читает другая программа, значит она может определить,
присутствуют там данные, или нет; значит может и удалить его

кстати, существование файла без данных может служить признаком того, что какая-то работа производилась,
пусть и с нулевым результатом

Здравствуйте, eao197, Вы писали:

E>Показательно, что начинают доказывать разницу между пользователем и заказчиком программисты.

E>Между тем ситуация очень ясна: пользователь программы говорит -- мне не нужны пустые файлы. Значит, программист должен рассматривать это как недостаток своего продукта. Недостатки нужно устранять, поскольку продукт с недостатками может привести к потере заказчика. А если (в пределе) программист теряет работу потому что заказчик отказался от продукта из-за неустраненных недостатков, то, censored, ЕСТЬ ЛИ РАЗНИЦА В ТОМ, УКАЗАЛ ЛИ НА НЕДОСТАТОК ПОЛЬЗОВАТЕЛЬ ИЛИ ЗАКАЗЧИК?
Все таки разница есть. Одни платят, другие желают но не платят. Для первых исполнение желаний обязательно, если он за эти желания заплатил. Для вторых желательно, ибо всегда есть желание быть полезным, ну и маркетинг рулит в будущих продажах.

Здравствуйте, igna, Вы писали:

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

Здравствуйте, rsn81, Вы писали:

R>А на поддержке не мучаться такими заоблачными проблемами, как создавать или не создавать пустые файлы.

Если ты прочитал пост, на который ответил, то знаешь, что что дело не в этом. Я баги пофиксил, поведения программы при этом не изменил, она как не создавала пустых файлов (точнее файлов только с заголовком и footer-ом), так и не создает. Но обратил внимание, что приведшие к появлению этих багов изменения программы, не привели бы к их появлению, если бы с самого начала не было решено предотвращать создание пустых файлов.

Здравствуйте, igna, Вы писали:

I>Мнение программиста: Если пустой файл никому не мешает, нечего и избыточную логику в программе городить.

Что за синематограф? Раз просят, значит — мешает.

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

Что за спор?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Что за синематограф? Раз просят, значит — мешает.

Не мешает. Спрашивал.

Здравствуйте, igna, Вы писали:

ГВ>>Что за синематограф? Раз просят, значит — мешает.
I>Не мешает. Спрашивал.

Тогда я, что-то, ничего не понимаю.

Вот это

Автор: igna
Дата: 07.02.08

, получается, нужно считать темой беседы?

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот это

Автор: igna
Дата: 07.02.08

, получается, нужно считать темой беседы?

Да. В этом конкретном случае возможно не стоило предпринимать даже минимальные усилия для того, чтобы избежать создания бессодержательного файла. Или обобщая, не стоит обрабатывать какой-то частный случай, если поведение программы для общего случая удовлетворительно.

Здравствуйте, igna, Вы писали:

ГВ>>Вот это

Автор: igna
Дата: 07.02.08

, получается, нужно считать темой беседы?

I>Да. В этом конкретном случае возможно не стоило предпринимать даже минимальные усилия для того, чтобы избежать создания бессодержательного файла. Или обобщая, не стоит обрабатывать какой-то частный случай, если поведение программы для общего случая удовлетворительно.

Унутреннее противоречие. "Общий случай" — такого вообще не бывает в технике. Это философская абстракция, обобщение. Все случаи — конкретны и, следовательно, частны. Однако, вполне возможно, что для некоторого частного случая поведение программы не определено или определено не корректно.

Короче, это всё очень просто.

Введём несколько утверждений:

P — истина, когда работает программа.
D — истина, когда есть входной поток данных, преобразуемый в выходной файл.
W — истина, когда входные данные могут быть выведены в файл, т.е. процесс их обработки проходит (прошёл) успешно.
F — истина, когда появляется выходной файл.

Нормальная последовательность такова (-> — импликация):

P -> D (Запустили программу, можем принимать данные)
D -> W (Приняли данные, можем их обрабатывать)
W -> F (Обработали — выталкиваем в файл)
(1)

В точке (1): F = P & D & W. Это то, как обычно понимают процесс вывода программой некоторых данных: программа запущена (P), есть входные данные (D) и есть повод что-то в выходной файл записать (W).

У тебя получилось:

P -> F' (Запустили программу, создали "подготовленный файл")
F' -> D (Создали файл — готовы принять данные)
D -> W (Приняли данные, можем их обрабатывать)
W -> F'' (Обработали — выталкиваем в файл)
// А потом вам добавили ещё:
We -> F''' (We — конец обработки, F''' — завершающая последовательность)
F''' -> F (Наконец-то!)

То есть первоначальное выражение, описывающее процесс, усложнилось: F = P & F' & D & W & F'' & We & F'''.

И где здесь общий и частный случай? ИМХО, просто не стоило ставить телегу впереди лошади и писать заголовок до получения результата обработки первых порций данных. Как пить дать, выиграли один if. Зато влепили ограничение на структуру файла, это я о заголовке. Описание же того, как связывали запись footer с выводом "второй" последовательности, чтобы поправить положение дел, может служить почти классической иллюстрацией к тому, как не надо такие вещи делать.

Собственно, это я к чему? Если программа спроектирована без глупых допущений, перемешиваний выхлопной трубы и карданного вала и неуместных оптимизаций, то и вопросов, подобных твоему не возникает. Поэтому здесь надо не гадать относительно "общности" и "частности" случаев (подобными рассуждениями в таких ситуациях пущай манагеры балуются, всё равно не им программы писать), а просто исправить это хозяйство и всё. Что ты, судя по всему и сделал. И это и есть единственно правильный подход.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> ИМХО, просто не стоило ставить телегу впереди лошади и писать заголовок до получения результата обработки первых порций данных.

Не совсем так. Там данные уже были, просто вместо того чтобы написать:

if (!(первая_последовательность.Empty() && вторая_последовательность.Empty())) {
    header.Write(stream);
    первая_последовательность.Write(stream);
    вторая_последовательность.Write(stream);
    footer.Write(stream);
}

оставили как было:

    первая_последовательность.Write(file_name);
    вторая_последовательность.Write(file_name);

, а вывод header-а и footer-а засунули в методы Write первой и второй последовательности.

Почему сделали такое безобразие? Там были две как бы причины, во-первых на самом деле программа пишет несколько файлов, причем во всех остальных случаях только одну последовательность в файл, потому каждый Write свой файл сам и создает; во-вторых Write принимал file_name, а не stream, а Empty последовательностей вовсе отсутсвовали. У программиста в голове случилось то ли замыкание, то ли наоборот, и он нашел "простое решение".

Не хочу о(б)суждать то как это было сделано, написал, чтобы было ясно о чем идет речь.

ГВ>Собственно, это я к чему? Если программа спроектирована без глупых допущений, перемешиваний выхлопной трубы и карданного вала и неуместных оптимизаций, то и вопросов, подобных твоему не возникает.

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

Здравствуйте, igna, Вы писали:

I>Ситуация: Функция/метод создает файл, пишет в него некий заголовок и передает его дескриптор или связанный с ним поток другим функциям/методам, которые тоже иногда пишут кое-что в этот файл. А иногда не пишут.

I>Запрос пользователя (change request): Если никакой информации кроме заголовка в файле нет, нечего и файл создавать.

I>Мнение программиста: Если пустой файл никому не мешает, нечего и избыточную логику в программе городить.

I>А вы что скажете?
А в чем проблема передавать другим ф-ия не дескриптор, а некоторый класс-обертку? Эта обертка будет отвечать за запись заголовока и footer.

Здравствуйте, darkker, Вы писали:

D>А в чем проблема передавать другим ф-ия не дескриптор, а некоторый класс-обертку? Эта обертка будет отвечать за запись заголовока и footer.

Согласен, так и нужно поступать, если действительно необходимо избежать создания "пустого" файла. Но я все больше склоняюсь к тому, что в данном случае этого делать не стоило (хотя открывая тему я был скорее другого мнения). Настоящей необходимости не было, было — скажем так — необоснованное желание пользователя, который сам же в конце концов и пострадал.

PS. Пользователь в данном случае не заказчик, программист и пользователь от заказчика равноудалены.