How to avoid wasting screen space writing sparse C# code?

Question

The commonly accepted way to format C# code seems to be as follows:

namespace SomeNamespace
{
    namespace SomeSubNamespace
    {
        class SomeClass
        {
            void SomeFunction()
            {
                using (var someFile = new StreamWriter(somePath))
                {
                    try
                    {
                        lock(someCriticalSection)
                        {
                            using (var someDisposableThing1 = new DisposableThing())
                            {
                                DoSomething();                            
                                using (var someDisposableThing2 = new DisposableThing())
                                {
                                    lock(someOtherCriticalSection)
                                    {
                                        DoSomethingMore();
                                    }
                                }
                            }
                        }
                    }
                    catch(Exception e)
                    {
                        Log(e);
                    }
            }
        }
    }
}

This wastes a large amount of screen space, both horizontally and vertically. I'm surely not the first person who notices. My question is: do you live with it, or have you developed a different formatting style to avoid an excess of white space?

PS: Note that I didn't even use a single if statement yet!

Answer 1

I tend to write small classes, short methods with small level of nesting. Not only you can see everything on your screen, also the code is better!

Answer 2

I have a 24" widescreen monitor. I greatly prefer "pretty-printing" over reclaiming space. Condensed, crammed-together code is hard to read and hurts my brain.

Answer 3

1. I don't often see namespaces nested in that way - maybe it happens, not where I work
2. I live with it. And mostly don't write such deeply-nested code. Having shorter methods, or methods with less nesting certainly reduces the horizontal whitespace problem, and having methods broken up into smaller pieces means you can get more important information in a given amount of vertical space.

Answer 4

Well I bought an HD monitor ;)

But the only way to deal with it apart from using less indenting would be to move some code into their own methods.

Answer 5

If I'm going to try/catch something, I would combine with any adjacent using blocks. Similarly, I would aggregate namespaces, so something closer to:

namespace SomeNamespace.SomeSubNamespace
{
    class SomeClass
    {
        void SomeFunction()
        {
            StreamWriter someFile;
            try
            {
                someFile = new StreamWriter(somePath);

                lock(someCriticalSection)
                {
                    using (var someDisposableThing1 = new DisposableThing())
                    {
                        DoSomething();                            
                        using (var someDisposableThing2 = new DisposableThing())
                        {
                            lock(someOtherCriticalSection)
                            {
                                DoSomethingMore();
                            }
                        }
                    }
                }
            }
            catch(Exception e)
            {
                Log(e);
            }
            finally
            {
                if( someFile != null )
                {
                     someFile.Dispose();
                }
            }
        }
    }
}

Answer 6

Don't think it looks so bad either ;) Making shorter functions however really is a point. In particular, it's nice if you can do stuff like replacing

if (condition)
{
   // bla
}
else
{
  // blub
}

by

void someFunction()
{
  if (condition)
  {
    // bla
    return
  }
  // blub
}

Answer 7

Let me explain it like this. If you really happen to encounter a nested code construct as deep as the one you show above, then the problem is probably not the formatting but your code structure.

You should consider taking a look at this: Refactoring by Martin Fowler

By extracting methods you improve not only the "wasted" screen space, but you dramatically increase readability too ;)

Another solution is always: Alt + Shift + Enter in Visual Studio to go into Full Screen mode

Answer 8

I agree with the other answers that I basically live with it -- for my team we either have high-res monitors or dual monitors (or both), so it's not like we're developing on 800x600.

But one thing to keep in mind is that your tabbing would be better off if you used actual spacing, as some developers use 2 spaces for a tab, some 4, some 6. So while formatted code may look fine on one developer's IDE, it may not look so good on another's. (I've seen some horrible outcomes from that.)

VS2010 has a nice plug-in from the Extensions Manager called the Productivity Tools that detects when you have a mix of tabs and spaces in your file and allows you to convert everything to tabs or spaces ("Fix Mixed Tabs"). It really helps to clean up your file (even if it doesn't look like it does anything!). It's great if you're sharing code across teams.

Answer 9

Tools > Options > Text Editor > All Languages > Tabs > Indent size > 1
Not a great solution... :P

Answer 10

use CodeRush , it'll make navigation through out your code much better

you'll get something like this

Answer 11

I've seen open brackets on the beginning line of a code block as in:

namespace SomeNamespace { 
    class SomeClass {
        void SomeFunction() {
            using (var someFile = new StreamWriter(somePath)) {
                try {
                    lock(someCriticalSection) {
                        using (var someDisposableThing1 = new DisposableThing()) {
                            DoSomething();                             
                        }
                    }
                } catch(Exception e) { 
                    Log(e); 
                } 
            }
        } 
    } 
} 

Less real estate, but I think its ugly.

Answer 12

You should read Bob Martin's Clean Code. It helps with this problem. In this instance, SomeFunction() does more than one thing. Split out each thing it does in its own method.

 namespace SomeNamespace.SomeSubNamespace
 {
    class SomeClass
    {
        void WriteToFile()
        {
            using (var someFile = new StreamWriter(somePath))
            {
                lock(someCriticalSection)
                {
                   ExecuteCriticalSection();
                }
            }
        }
        void ExecuteCriticalSection()
        {
            using (var someDisposableThing1 = new DisposableThing())
            {
            DoSomething();
            ExecuteFinalCriticalSection();
            }   
        }

        void ExecuteFinalCriticalSection()
        {
            using (var someDisposableThing2 = new DisposableThing())
            {
            lock(someOtherCriticalSection)
                {
                DoSomethingMore();
                }
            }
        }
    }
}

Also, don't catch a System.Exception; you never know what's going to fail, and you shouldn't try to catch exceptions you can't handle. Let them bubble up and die horribly.

Answer 13

In addition to what others have said here, the one thing I do to lessen the effect, is to use a proportional-spaced font. The text is more readable, but not nearly as wide. It also forces you to use tabs over spaces for alignment (which is of course, why the good Lord gave us tabs in the first place)

I personally use Comics Sans MS, but that really drives coworkers crazy....

Answer 14

The using statement is very handy, but if code becomes harder to read you can do without it:

namespace SomeNamespace.SomeSubNamespace
{
    class SomeClass
    {
        void SomeFunction()
        {
            StreamWriter someFile = new StreamWriter(somePath);
            DisposableThing someDisposableThing1 = null;
            DisposableThing someDisposableThing2 = null;

            try
            {
                lock (someCriticalSection)
                {
                    someDisposableThing1 = new DisposableThing();
                    DoSomething();
                    someDisposableThing2 = new DisposableThing();
                    lock (someOtherCriticalSection)
                    {
                        DoSomethingMore();
                    }
                }
            }
            catch (Exception e)
            {
                Log(e);
            }
            finally
            {
                // requires SafeDispose extension method
                someFile.SafeDispose();
                someDisposableThing1.SafeDispose();
                someDisposableThing2.SafeDispose();
            }
        }
    }
}

Answer 15

Some general ideas:

• Combine those namespace blocks into one.
• Gather using statements into one place, if you can.
• If you're not a fanatic "Even single statements need enclosing {}s!", you could get rid of the brackets between the using and the try..catch blocks.
• Think about whether nested locks are really required, or if the outermost lock will suffice.

These could result in the following code (take note that the meaning of your hypothetical example code may not be exactly preserved):

namespace SomeNamespace.SomeSubNamespace
{
    class SomeClass
    {
        void SomeFunction()
        {
            using (var someFile = new StreamWriter(somePath))
            try
            {
                lock(someCriticalSection)
                {
                    using (var someDisposableThing1 = new DisposableThing())
                    using (var someDisposableThing2 = new DisposableThing())
                    {
                        DoSomething();                            
                        DoSomethingMore();
                    }
                }
            }
            catch(Exception e)
            {
                Log(e);
            }
        }
    }
}

(You could even move the two usings to the other using statement outside of the lock, if your code would permit it. You could further replace using statements with explicit calls to Dispose in a finally block, as suggested in another answer.)