I'm...not going to let you do that

I was currently working on some error handling code for one of my side projects when I came across this problem. I have objects stored in a database, which of course has a field Id for its primary key. However, when the user goes to create this object, the Id field has no value until it gets saved to the database, as which point the database engine gives it an Id. The object in my code includes a member for the Id field of type int? (which is a nullable int, it can have a value of null). The function I use to get the object from the database is defined as such

     public Object GetObjectFromDatabase(int? ObjectId) { }.

Inside this method, if the value of ObjectId was null then I would return null as the object.

     if (ObjectId.HasValue)
     {
          // Get and Return the object
     }
     else
     {
          return null;
     }

Adding in my error code, I thought about that behavior and decided that if I was going to the database to get an object, I would need to know its Id, so I decided that passing in a null would be considered an error. So I changed that else statement to read

     else
     {
          throw CustomizedError;
     }

I still wanted the function to accept a nullable int to avoid checking if there was a value for Id and then convert it to a regular int for every place I call GetObjectFromDatabase. I have other functions that take in similar parameters, including updating the object, deleting the object, and other various things that can be done with the object, After some debate with myself, I changed those functions to only accept a regular int instead of a int? for three reasons.

1) Programmers can only make mistakes when the code allows them to. This is why we have private variables and enforced type checking. In languages like Javascript, bugs arise when strings get treated like numbers and vice versa. Javascript doesn't force the programmer to choose a type for thier variable and stick with it. It's just var Name; Take the following code
  
     var Two = 2;
     var Three = "3";
     alert(Two + Three);

The pop up you get will display "23". This would be a bug if the developer wanted 5. It's a simple mistake, but it happens because it was allowed to happen. If you tried that in C#, you wouldn't be able to compile. If I don't want programers to pass a null into this functions, I just need to not let them at all.

2) Bugs make it through testing all the time. I or someone else will eventually make the mistake of passing a null into that function, and, if I had testing for my project, since it would be a special case there is a good chance it would make it through testing.

3) It is always better not to have to throw errors. Even if it means more code to write. Sometimes having to write more code means you have to think through what you are doing. Also, bug-free code is sort of the goal and writing code that actually prevents bugs before it even compiles is preferable.

Book Finished: Mythical Man-Month

I just finished reading Mythical Man-Month by Frederick Brookes. It was pretty good, although a bit dry at times. It is a bit dated too although the 20th Anniversary Edition tries to updates the old material with a new chapter that includes discussions with others on the original material. Some of the points I took away from the book that I think are still applicable today for software projects are:

     - Adding people late in a project makes it late, or makes it later if it is already behind schedule. There is an initial overhead cost of training and the new worker to find their way and become familiar with the  project before they can fully contribute to the project. If you need more people, add them sooner than later to mitigate that cost.

     - The system architects and designers should stick to only architecture and designing and the coders should only stick to coding, that may you have a separation between design and implementation, otherwise implementation may influence or change the design to fit the implementation, which may cause problems with what is intended or if a decision is made to change platforms.

     - There should be as few designers and architects as possible, or at least as few people making decisions as possible, in order to preserve conceptual integrity and uniformity.

     - Communication is the hardest part about working on a team. The effort to communication and coordinate grows exponentially as the team grows in size. This means that doubling the work force will not double the productivity because the effort of communicate will more than double.

     - As much documentation as possible should be completed before any other work starts on a project. Writing documentation forces you to make decisions and ask questions you would otherwise put off or not know you had to make or ask. It is easier to implement things from the start rather than add them in later.

     - Despite the above point, the only real constant in a project is change, and so one must plan for changes to occur, not just in specifications in the project, but also for changes in the organization or the team performing the work.

     - Milestones need to have a clear and precise definition, otherwise confusion about progress may arise. If the definition is precise you cannot lie to yourself about progress and a person receiving a progress report will have close to the same understand of the progress as the person giving the progress report.

I've seen this book on a few required reading lists that some software developers have up on various blogs and website. I think it is worth a read as long as you pick up the 20th anniv. edition so you can understand what may or may not be still be applicable.

Double Post To Start Off Renewed Blogging Attempt

I'm doing two posts today in my renewed effort to blog. Don't expect this pace from me though. in fact, keep your expectations low.

Today I'm pointing out that clever code is not a good thing. You should code in a way that even non coders understand what you are trying to achieve (if you are using a high level language that is, if you are using a low lever language, then go ahead and ignore this advice, nobody will be able to understand anything you could write without a great deal of effort no matter what).  A quote by Brian Kernighan is "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

So you should write code like this:

          public string GetMonthAbbreviation(int MonthId)
         {
             switch (MonthId)
             {
                   case 1:
                              return "JAN";
                              break;
                    case 2:
                              return "FEB";
                              break;
                    case 3:
                             return "MAR";
                             break;
                    case 4:
                             return "APR":
                            break;
                     default:
                            return "N/A";
                            break;
'              }
          }

And NOT like this:

               private Dictionary<string, string> Monthlist;

               public Constructor()
               {
                     Monthlist = new Dictionary<string, string.>;
                     MonthList.Add("1", "JAN");
                     MonthList.Add("2", "FEB");
                     MonthList.Add("3", "MAR");
                     MonthList.Add("4", "APR");
                }

              public string GetMonthAbbreviation(string MonthId)
              {
                       return (MonthId != null && MonthList.ContainsKey(MonthID)) ? MonthList[MonthId] : "N/A";
               }

Which seems easier to understand?

Changing things up

I'm changing the way my blog works. Instead of posting only longer articles that are checked for spelling and grammar and then revised to sound better, I've decided to do much shorter posts. I'll still do the longer pieces, and there will be a post about them with a link as well as links to them on the site, but I want be more active with this. Attempting to write articles that equated to a school essay or paper doesn't seem to be working well for me, so I'm trying something different. Short posts for the most part, longer articles as pages on the site which will be accompanied by a blog post with a link to it, and I'm going to set up my google drive to host my custom code that people can download and use or just look at, which I will update a page with links to it and of course a short post to inform when I do updates. I most likely will not be putting up links on my Facebook and G+ accounts to new posts, but I will when I do something substantial. I'm not sure if I'll use Twitter to announce new blog posts. I've really stopped using Twitter, last time I was on it was just to tweet that I had a new post up (yeah, that long ago). Hopefully this get me writing more, unless blogging just really isn't my thing.