Эффективность Файлового ввода-вывода C#

Ваш способ выглядит неплохо, но:

• Было бы лучше, если бы вы использовали PascalCase для констант, так как это то, что используют соглашения кодирования для C #.
• вы должны обернуть StreamReader в оператор using, чтобы он был должным образом утилизирован, как только вы закончите.
• Вам, вероятно, также следует заключить его в блок try (и уловку для правильной обработки исключения), чтобы убедиться, что вы не получите исключение FileNotFound .
• Вероятно, лучше структурировать цикл while следующим образом:

while ((line = windChillDoc.ReadLine ())! = Null) { ... } [Чертово форматирование не сработает!]

Но кроме этого, я бы не знал, потому что я не знаком с расчетами погоды :)

Большинство ваших комментариев не имеют отношения к делу. Код должен рассказать вам, как ... комментарии должны рассказать вам, почему.

Незначительная придирка, но «WindChillCalc» должен быть «CalcWindChill», если вы используете Английские названия методов (глагол идет первым).

Почему делают / в то время как ? В вашем do вы проверяете значение null. В вашем , а вы проверяете значение null. Почему бы просто не сделать его оператором while ?

string line;
while((line = windChillDoc.ReadLine()) != null)
{
    //Logic
}

EDIT : исправлена ​​ошибка компиляции. Забавно то, что изначально это было у меня. Это поле Rich Text Box нуждается в компиляторе! : P

string filePath = "";
...
filePath = Console.ReadLine();

Не инициализировать значениями, которые никогда не используются; и держите объявление и инициализацию близко друг к другу:

string filePath = Console.ReadLine();

с использованием было упомянуто, но не используйте @ без необходимости:

new StreamReader(@filePath);

должно быть просто:

new StreamReader(filePath);

Лично я бы использовал LINQ для линейного читателя, но это только я ;-p

Если вас помечают по стилю и т. Д., То есть пара крайне незначительных вещей

• Инициализация двойных чисел в 0,0 избыточна.
• string.Empty предпочтительнее вместо ""
• Ваш метод windchill может быть изменен на простой (хотя во время компиляции я думаю, что wci будет оптимизирован - так что функционально он такой же):

(изменено форматирование для удобочитаемости SO)

static double WindChillCalc(double temperature, double ws)
{
    return FIRST_EQUATION_NUMBER + 
        (SECOND_EQUATION_NUMBER * temperature) - 
        (THIRD_EQUATION_NUMBER * (Math.Pow(ws, EQUATION_EXPONENT))) + 
        (FOURTH_EQUATION_NUMBER * temperature * (Math.Pow(ws, EQUATION_EXPONENT)));
}

В маленьких академических программах, подобных этой, производительность не будет проблемой, если вы не сделаете что-то действительно глупое. Простой способ определить, является ли производительность проблемой, - это задать вопрос: «Это заставляет меня ждать?»

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

Хотя на самом деле это не связано с производительностью (главный вопрос)

ИМО:

const double FIRST_EQUATION_NUMBER = 35.74;
const double SECOND_EQUATION_NUMBER = 0.6215;
const double THIRD_EQUATION_NUMBER = 35.75;
const double FOURTH_EQUATION_NUMBER = 0.4275;
const double EQUATION_EXPONENT = 0.16;

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

Я бы изменил degreeSymbol на константу, а не работал бы с константой int позже.

const char DEGREE_SYMBOL = (char)176;