As of right now, we haven’t covered Unit testing so I don’t have much to say about that although I have heard from CS friends that it is a very important tool.

However I have noticed a few things from doing C++ programming in QtCreator.

1) The compiler will usually spit out an error that pertains to what you did wrong, and should be a big enough hint fix it

2) The program compile, but exit with no error code

Having 2 happen is very frustrating, but after several months of working with Qt I can now confidently say that this usually only happens when some sort of memory is attempting to be accessed that does not exist or has not been initialized.

For example, for most projects in Qt some sort of List (QList) will need to be used.  In order to use a QList, the type of data members stored in the List must be specified (i.e. QList<QString>).  However, one must be very careful not to try to members in a List if they do not exist.

If a QList called listName exists, it is always preferable to used either listName.front() or listName.back() if there aren’t many things in the list and you just need one or two things.  If you need to cycle through the list, and get everything out of it, it can be helpful to make a temporary list, and pop_front() within a while loop that runs only while listName.size() > 0.

Before I figuerd this out, I would just use array-like functions to get to the data I wanted (ie listName[0] for the front).  However this is not good code because there can be unforseen consequences when you exist the list to have at least 2 or 3 members at all times.  By doing what I mentioned above, at least the program won’t quit on you without telling you what went wrong.

Unfortunately, I’ve had a massive workload over the last couple of weeks and as a result I’ve completely forgotten about this blog and haven’t posted to it.  I will try to post as much as possible over the next couple of weeks to make up for this.  Since I do alot of coding for my classes, I usually have a large amount of subjects to blog about.  The first subject, I would like to talk about is commenting code. As everyone knows, comments can make or break the code.  It allows the reader to know exactly what you’re doing and how each part of your code contributes to the whole.  Since comments are so important, I’m finding the lack of standardization on comments a little disturbing.  While there are various guidelines to how one should comment code, I firmly believe that there should be some sort of industry standard on code commenting, especially between different programming languages.  Even in the same programming language, there are so many different ways to comment your code and every person has a completely different way of doing it. For example, when coding in C, I prefer to add a short comment at the end of a line with // where I need to explain anything.  However, some of my professors like to use /* */ blocks on top of the code section, even when very little explanation is required.  I find that this sometimes disrupts the flow of the code.  You may be reading something and all of a sudden a big comment block pops up out of nowhere, and it potentially might not tell you anything important.  Additionally, different commenting styles can result in random placement of code that results from differences in indentation.  Someone may be using tabs and // after lines to comment and it may look perfectly fine in one development environment, but someone else opening the file up may have skewed commenting due to different screen sizes and tab/space differences.  Without some sort of standardization, individual commenting styles can be cluttered and messy. I also think there should be some sort of standardization across programming languages.  For example, python coding uses #, C coding uses either // or /**/, and I believe HTML uses <!– –>.  While it is understandable that they are all different for different reasons, if all coding languages had the same comment markers, it would streamline the process.  Adding that to a commenting standard that specifies where, when, and how to comment, it may potentially allow any programmer to read code in any programming language.  This can be good for both education and practical purposes.