Evaluation is a difficult task and when it bundles up with having a set perspective, it may blow your brains out. Rating a piece of code/content on the no of lines the coder writes will not establish the skillfulness of a programmer. For instance, writing a complicated algorithm might require a lot of time and result in only a few lines code, making the quantitative approach unfair. So how do you rate a content at the first look? How does one hover their programmer’s eye on the content to grasp the most out of it with a glance?
Well the answer is as difficult as the question but here are some pointers to help you the next time you judge a content from a programming POV.
To establish the quality of the code, the program’s project goals should be used as criteria. When a change in the code leads to a better assessment of the objective, the code makes a positive contribution and vice versa. The modularity, reusability and effectiveness of the code are few things to always keep at the top of your mind.
The visualization of large amounts of data helps a programmer in writing an optimized and effective code. Understanding the thought process of the programmer behind his approach is an important aspect of the evaluation process. A good visualization may have the following favorable outcomes in the long run:
- Enablement of parallel processing
- Store large amounts of data in an easily accessible form
- Group related information, enabling easy search and access.
- Represent large data in a small space.
- Reduce task complexity
- Allow visual information recognition
- Increase pattern and event recognition etc.
The Q list
I call it the Q list for a reason. It helps you think of questions that a programmer’s code will answer instantly. You base metrics for judgment will start showing up values when you get the answers to your questions. This is inspired by the Goal-Question-Metric approach which helps you understand a content thoroughly. A few basic questions can start with the ones below:
– How many lines of code does a programmer write?
– How many lines of commentary is used?
– How does the program affect the complexity of the system or its subcomponents?
– How does it affect the cohesion of the system or its subcomponents?
– Does a program make many small commits or does he make a few large ones?
The overall feel and functionality testing
This is a sacred metric for me personally. I am not sure how many would use it but aesthetics (Indentation, semantics etc.) and overall functionality matter a lot in distinguishing a good code from an okayish one. If the code doesn’t feel good it might not work out well. Well, it might be one of those musician things that we don’t really like/sing the songs we do not feel :P. But yes it does matter. If the song doesn’t serve the purpose the lyrics are written for, the marriage of music and poetry is a fail! Same goes for the code and functionality it is meant to serve.
As stated before, the answers are as difficult as the questions, I hope this makes your lives easier. The guidelines above are not just for peer evaluation or external evaluation rather you can also chew on these thoughts while reviewing a content of your own. Step into the shoes of an evaluator and make your program, check ready! 😉
“A true genius resides in the capacity for evaluation of the uncertain, hazardous and conflicting information.”