Statement Refactoring

I've just noticed this somewhere:
public string MakeRequest(string hostname, string message)
{
    Socket socket = null;
    IPAddress serverAddress = null;
    IPEndPoint serverEndPoint = null;  
    byte[] sendBytes = null, bytesReceived = null;
    int bytesReceivedSize = -1, readSize = 4096;
    serverAddress = Dns.Resolve(hostname).AddressList[0];
    serverEndPoint = new IPEndPoint(serverAddress, 80);
    socket = new Socket(AddressFamily.InterNetwork,
    SocketType.Stream, ProtocolType.Tcp);
    bytesReceived = new byte[readSize];  
    sendBytes = Encoding.ASCII.GetBytes(message);
    socket.Connect(serverEndPoint); 
    socket.Send(sendBytes);
    bytesReceivedSize = socket.Receive(bytesReceived, readSize, 0);
    socket.Close();
    if(-1 != bytesReceivedSize)
    {
        return Encoding.ASCII.GetString(bytesReceived, 0, bytesReceivedSize);
    }
    return "";
}
Why do programmers still write code like this in C#? Do they like verbosity? Why not write this instead:
public string MakeRequest(string hostname, string message)
{
    IPAddress serverAddress = Dns.Resolve(hostname).AddressList[0];
    IPEndPoint serverEndPoint = new IPEndPoint(serverAddress, 80);
    Socket socket = new Socket(AddressFamily.InterNetwork,
                               SocketType.Stream, ProtocolType.Tcp);
    int readSize = 4096;
    byte[] bytesReceived = new byte[readSize];  
    byte[] sendBytes = Encoding.ASCII.GetBytes(message);
    ...
}
It seems to me there are loads of these statement level refactorings that would prove really useful. Do any tools support "small" refactoring like this? Do any books talk about them?

Here's another: Instead of writing:
if (expression)
    return true;
else
    return false;
why not just write:
return expression;

10 comments:

  1. One reason I may expand code that looks like the latter into the nasty former is if I am debugging and I want to insert e.g. print statements to indicate the intermediary valuse on console output, or similar. I realise this is a very primitive way to debug things, but I still do it. With the much-touted aspect-oriented programming, would this still be necessary?

    ReplyDelete
  2. The problem is it's a bad idea (IMHO) to write code in a certain style because its easier to debug. It kind of presupposes there will be bugs. The idea is that there aren't any bugs! In practice there are of course. The question is how to fight them. I think the best way is to write clean code, and to design it so its testable so as to avoid style fudging such as this. If you're not careful you can easily end up in a style that actually encourages the bugs and thus you end up in a kind of self fulfilling prophecy... Very Zen!

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. Anonymous6:08 pm

    This comment has been removed by a blog administrator.

    ReplyDelete
  5. Anonymous7:24 pm

    This comment has been removed by a blog administrator.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete
  7. This comment has been removed by a blog administrator.

    ReplyDelete
  8. This comment has been removed by a blog administrator.

    ReplyDelete
  9. James Dennett5:01 pm

    I have to agree with Jon; a large fraction of bugs are in code because it's (a) not clear/simple enough and (b) not tested enough. A lack of testing is often related to the code not being clear/simple enough -- so any "debugging-friendly" style that obscures what the code is doing (as making it more verbose often does) is likely to introduce bugs. A focus on clarity and testing pays off better.

    ReplyDelete
  10. The visitor pattern is tight coupled in one direction(visitor needs to know visitable concrete objects so adding new visitable objects can be done only changing all existing iterators). A way to reduce it is to use reflection another one is this one ...

    ReplyDelete