Преимущества (и недостатки) вызовов вложенных методов C#

Question

Я возвращаюсь к кодированию на C#, после того, как он глубоко вставляется в Objective-C. И мне было интересно, на C# есть ли какие-либо особые преимущества или недостатки для написания кода с вложенными вызовами методов с точки зрения производительности, издержек памяти и чтения кода? &? Или лучше идти с более легким для чтения и/или более легким выполнением кода, с любой возможной скоростью или преимуществами памяти (частью преимуществ памяти может быть разговор с ObjC/non-managed code)?

Пример (х, у, г, ш, т, е & г все ИНТ в):

// non-nested 
// someMethod returns an int 

int b = someMethod(w,t,e); 
int a = ((x + y) * b); 
int c = a + (b * g); 
return a + b + c; 


// nested 
// someMethod returns an int 
return (((x + y) * someMethod(w,t,e))) 
+ (someMethod(w,t,e)) + (((x + y) * someMethod(w,t,e)) 
+ (someMethod(w,t,e) * g)); 

легче следовать без вложенного кода, но во вложенном коде вы не необходимость создания трех переменных; это также четыре строки кода для одной строки кода (хотя одна строка разбита на три строки для удобства чтения). Я просто не уверен, какой путь лучше или более принят в сообществе разработчиков C#. Любое понимание было бы высоко оценено. Благодаря!

Answer 1

Если someMethod(w,t,e) делает что-то нетривиальное, вызов его три раза будет медленнее, чем выполнение одного вызова и сохранение результата.

Обратите внимание, что два выражения эквивалентны только в том случае, если функция someMethod(w,t,e) является «чистой» функцией, что означает, что она свободна от побочных эффектов и что она возвращает одно и то же значение для одного и того же набора аргументов.

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

Answer 2

Считываемость почти всегда лучше. Посмотрите книгу под названием Clean Coding. В вашем примере будет использоваться еще одна дополнительная память, как только будет создан код.

Answer 3

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

1. Как вы уже упоминали, это легче читать, поэтому, если ваш код когда-либо передается, или если вы повторно его просмотрите через некоторое время, вы сможете быстро понять, что происходит.
2. Вы можете сделать код, который можно многократно использовать. Что может сократить время кодирования в больших проектах
3. Это облегчает отладку, потому что вы можете быстрее изолировать проблемы.

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

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

Он хранит все просто, чисто и удобочитаемо.