So You Want To Be A Code Reviewer? #5 Part 1 - Method Design

preview_player
Показать описание
#codereview #codereviewer
Being a Code Reviewer comes with responsibilities. First and foremost is that your own coding needs to be top notch. In this series, I'll discuss code and the issues with snippets of code. I'll explain the What the Why and the when of the issues with the code presented and what the correct way of writing the code is.
Рекомендации по теме
Комментарии
Автор

Great video once again Shiv - there is always something which I can take out from your videos. You are one of very few people who can actually challenge my belief in certain practices and make me rethink and reevaluate them.

hansrudolf
Автор

It is my understanding that try-finally has very little overhead (the overhead is in throwing exceptions in general) and so I would prefer to use `using` multiple times to doing it by hand (as in your example). Not only is it more readable (especially with the new syntax), it is also less error prone. Short of doing really 'sub-optimal' things with regards to performance, it is my experience that it is better to profile before you optimize (the performance problem is never in the area you would have guessed).

obiwanjacobi
Автор

Shiv, thank you for this video. Learnt a lot like
attention to small detail,
do the things even they appear too small(be meticulous and consistent),
write more intentful code not just code following best practices,
not to write null checks in all places( for this to achieve, lock front and backdoor, and you are safe frominvalid data)!
Getting things working is not great job! (rather getting thing done using best possible way is struggle to achieve)...etc.


can you please tell what does GC.SuppressFinalize do?

VinuP
Автор

Hai Shiv

Thank you for your explanation

A short question about Using Statements

I have a disposable class

public class TestDisposable: IDisposable
{
public void Dispose()
{
}
}

Case 01:


static async Task Main(string[] args)
{
using (var myDisposableFirst = new TestDisposable())
using (var myDisposableSecond = new TestDisposable())
using (var myDisposableThird = new TestDisposable())
using (var myDisposableForth = new TestDisposable())
{
try
{

}
catch (ArgumentNullException ex)
{
throw;
}
}
}



IL for Case 01:

{
// {
IL_0007: nop
// <myDisposableFirst>5__1 = new ApartmentDisposable();
.try
{
// <myDisposableSecond>5__2 = new ApartmentDisposable();
IL_0013: ldarg.0
.try
{
<myDisposableThird>5__3 = new ApartmentDisposable();
ldarg.0


<myDisposableForth>5__4 = new ApartmentDisposable();




{
nop


nop
// end .try


{
stloc.1
// end handler



// end .try


Case 02:


static async Task Main(string[] args)
{
using (var myDisposableFirst = new TestDisposable())
{
using (var myDisposableSecond = new TestDisposable())
{
using (var myDisposableThird = new TestDisposable())
{
using (var myDisposableForth = new TestDisposable())
{
try
{

}
catch (ArgumentNullException ex)
{
throw;
}
}
}
}
}
}

IL For case 02:

.try
{
// {
IL_0013: nop

.try
{
// {
IL_001f: nop
// <myDisposableThird>5__3 = new TestDisposable();
.try
{
{
nop


{
nop


nop
}
nop
leave.s IL_0047
// end .try





In both cases IL Code is almost the same, is removing curly braces just for syntax preference or as you mentioned will it removed nested try finally's? [ I used ILSpy for this]

As you mentioned that if we use levels of using statements "will cost something" if you do not mind may I know what can happen exactly?

akhilbandari