Casual projects on Github omit error checking, logging, etc., for the sake of clarity?

Question

I just started using GitHub to socialize some projects for simple chat and peer-to-peer apps. With respect to coding, is it customary to omit exception handling, error checking, logging, etc., to promote easy-to-understand and 'clean'-looking code, if those additions are not completely necessary to actually run the code?

For instance, here's two extreme examples:

   if( msg != null){
      NodeEvent event = NodeEvent.valueOf(msg.getAction());
      switch (event) { 
        case NODE_CONNECTING:
          if( nodeName.isInvalid())
             Utils.log("Invalid node name, ignoring...");
          else{
             String existingNodeAddress = _nodeNameAddressMap.get(nodeName);
             if( existingNodeAddress != null)
                Utils.log("Node address for '" + nodeName + "' updated");
             else
                Utils.log("New node '" + nodeName + "' connected"); 

             _nodeNameAddressMap.put(nodeName, nodeAddress);
          }
    }

Here's the same snippet minus the fluff, although this version can easily crash if fed bad data, but otherwise it will compile and run fine:

   NodeEvent event = NodeEvent.valueOf(msg.getAction());
   switch (event) {   
     case NODE_CONNECTING:
        _nodeNameAddressMap.put(nodeName, nodeAddress);

The clean version is easier to read, obviously, but is brittle. The verbose version is safer, it just looks cluttered.

I'm just curious to know if it's more effective for a social projects to go for the cleaner look at the expense of fragility, allowing those who fork the project to fill in the blanks. A quick survey of github projects and it's clear most go for the clean look.

Answer 1

I think you are confusing writing books that talk about code vs. writing code that is meant to be executed by an actual computer.

"for brevity" is something a book author says when he wants to illustrate a point and the reason why the author says that is so that when you read that book, you focus on his intended point, but you also understand that this code is incomplete and SHOULD NOT be taken as a direct example of how one should write code.

When I start a project, almost the very first thing I do is define standard logging scheme and make sure there is a convention in place for handling errors. I'm not doing it "to be complete" but because when I write code, I will introduce bugs and even if I don't, things will go wrong. Personally, I'd rather spend 4-8 hours upfront ensuring I have a log file maybe even with ability to change logging level, than write a whole bunch of code only to stumble upon a bug and realize that everything I've written is a black box and I have no idea where it is failing or even where to start looking.

And if you don't have error handling, that means instead of identifying stack traces where the error/crash occurred and actually calling out places that failed (i.e. that system call that didn't return a resource), your app will go on only to crash/fail elsewhere, potentially masking the real problem in the process

Logging/error handling is only there to help you go faster in the long run. But in the end, it's completely up to you. If you believe you can accomplish a project faster and meet some kind of quality standard (i.e. "is your app actually usable" would be a standard) without handling errors, then go for it. Logging/error handling are only tools to help you get there faster with less effort, but just like with any tool, you decide if they are worth it. But from my experience, in just about every project I've ever done, they absolutely were.

Answer 2

On Github, many people are marketing their open source project, rather than storing and sharing it. I noticed just yesterday that the recommended use case for one of the networking libraries I use on a day to day basis does not actually check if the server exists before assuming the connection succeeded.

People want their example to seem incredibly simple, so that you pick up their library and do something with it. Error conditions are an afterthought, because if you have to look at a real-world example (which might be several times as long) compared to the provided example, the provided example will always look prettier.

CPAN has always taken somewhat of a different tack with this - generally it's very clear from the docs what the proper usage of the module is, including any error checking required.

Be more like CPAN, and less like the responsive, expressive, agile, dynamic, synergistic frameworks you find on Github.

Answer 3

If this is code intended to run in live environments (actually used in real programs), include all the necessary error checking and logging. If its meant for teaching purposes only, you can safely leave it out for clarity sake. But make sure you mark it as such. You may even want to include such teach code only inside documentation, so there's no confusion.

Also keep in mind, if you are using this code as a showcase for potential employers, if they run it and it has tons of unhandled exceptions, how is that going to make you look?

Answer 4

Here's the thing with error checks like the prints you've inserted; they're not really all that necessary if you're using good source control (and if you're using GitHub, you're using Git, so you are). Learn to use it well and you won't have to ask yourself such questions. It also says that you might not be using automated tests in the best possible way.

If I read code like that I might make some assumptions like "This person is kind of an amateur" or "This person doesn't know how to use source control very well". I might also think "This code has been vetted pretty well" or "This person has a good thought process". How I think depends on the situation, but leaving in the prints means I might think the former way more than the latter.

The code you post says something about you as a coder. Just keep that in mind.