- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
public string ExportToFile(string filename, string filepath, DataSet dsInput)
{
string sFlag = "Error";
System.IO.StreamWriter sw = new StreamWriter("");
try
{
if (filename.Trim() != "" && filepath != "" && dsInput.Tables[0].Rows.Count != 0)
{
sw = new System.IO.StreamWriter(filepath + filename + ".xls");
int iCol = dsInput.Tables[0].Columns.Count;
for (int i = 0; i < iCol; i++)
{
sw.Write(dsInput.Tables[0].Columns[i]);
if (i < iCol - 1)
{ sw.Write("\t"); }
sw.Write(sw.NewLine);
foreach (DataRow dr in dsInput.Tables[0].Rows)
{
for (int i = 0; i < iCol; i++)
{
if (!Convert.IsDBNull(dr[i]))
{
sw.Write(dr[i].ToString());
}
if (i < iCol - 1)
{ sw.Write("\t"); }
}
sw.Write(sw.NewLine);
}
sw.Close();
sFlag = "Success";
}
}
return sFlag;
}
catch (Exception)
{
return sFlag;
}
}
Follow us!
Orly? Имхо, осмысленность этой венгерской херни совершенно не зависит от языка и типизации. А если подумать - для утиной она даже полезней, т.к. никакой инфы о типах помимо документации там нет, а что попало передавать никто не разрешал.
Мы же обсуждаем точку зрения человека, а не рантайма.
Копаться в проекте в 25k LOC с неявной питуизацией, без доки по классам/методам (включая приватные) - злейшему врагу не пожелаю такой участи...
в библиотеке конгресса?!!!
> в библиотеке конгресса
Она такая маленькая? Фи.
> даже комментов нет?
Это риторический вопрос.
А вообще - в main'е есть годный и большой вводный коммент с описанием архитектуры, но его малость недостаточно. Остальные комменты - по мелочи, в сложных местах.
P.S. В принципе, я ничего не имею против такого стиля документирования. Я и сам почти всегда так делаю - большой вводный коммент по модулю + подсказки в сложных местах. И на языках со статической типизацией этого более чем достаточно...
Грамотный код не нуждается в комментариях и документации. вот только писать такой код могут не только лишь все....
А читать - тем более.
Нету хотя бы краткой доки по рахитектуре и идеям - читай весь код @ восстанавливай мысли автора. А влом же.
ну это уже проблема компетентности программиста. может он больше поломойка чем программист
>>Нету хотя бы краткой доки по рахитектуре и идеям - читай весь код @ восстанавливай мысли автора. А влом же.
против краткой возражений не имею. Диаграмма классов, краткое описание модулей, классов и паблик методов - норм. Но иногда такие нечитамые портянки в документации, столько воды, которая порой наоборот только путает, что страшно становится.
С другой же стороны если код адовый и был писан бухим марсианином - никакая документация не поможет
В том, что его нужно читать. У меня лично мало желания читать тыщи строк кода на каждый чих. Хороший код обычно можно и не комментировать (в основном за счёт правильных имён, а выбор правильных имён, как известно, является одной из двух основных проблем в информатике), но вот любые интерфейсы нужно документировать тщательно.
Ну и один из самых лучших видов документации - примеры использования для типичных сценариев.
мне обязательно было дописывать интерфейсы, проперти, енумы и т.д?
http://root.cern.ch/root/htmldoc/TPad.html - и так без бутылки не разберёшься, но если бы не было той маленькой диаграммки, понадобился бы ящик.
Я имел в виду интерфейсы в широком смысле, не в узком. Любые интерфейсы, границы библиотек, модулей, протоколы, etc.
Я всё время говорил по-русски и думал, что надо "кай скуаре" :(
зайшкваред
Просто с явной типизацией я бы это сделал быстрее.
В код сервера я заглядываю достаточно редко - это не моя работа, - только когда нужно обновить локальную среду разработки, мигрировать таблицы, добавить недостающие шаблоны и т.п. Не смотря на то, что Джанго сам по себе не маленький, и наши написали там еще кучу всего, как правило, я довольно быстро справляюсь с настройками.
Флешевая часть написана с использование Флекс + ПурЭмВэЦе, писатели смогли так запутать все ходы и выходы, что после полгода работы я просто забил на ту чать проекта, за которую мне не отвечать. Чтобы объяснить почему так получилось, представим типичный пример использования:
где-то хз. где:
и где-то там же:
Т.е. от того, что все типы проставлены, никому легче не стало. Типы не предохраняют от ошибок типа registerNotifications() случилось после того, как facade.sendNotification(). Более того, типы не описывают смысл происходящего в приложении - от того, что я знаю какой тип у GlobalConstants.SOME_CONSTANT, или у SomeData ровным счетом ничего не меняется - мне это не дает никаких преимуществ в смысле поиска зависимостей и понимания смысла происходящего.
Т.е. у типов есть возможность их использовать для того, чтобы сделать код более понятным, но их использование само по себе не реализует эту возможность. В конце концов можно написать всю программу используя только численные типы, или, например, только числа и хеш-таблицы. От того, что типы будут проверены на этапе компиляции такая программа лучше не станет.