Whenever I interview for a prospective position (freelance or otherwise), the interviewer always asks at the end of the interview, "Do you have any questions?".
I almost always have at least one: "Could I see your standards documents? You know: design, coding, error tracking, etc.?".
I'm really less interested in seeing the actual documents (although I do want that), than wanting to see if they even have standards. Some don't; a good sign that it is not a well-run project. Unless they want to pay me to write their standards before doing anything else, I avoid those projects; they are always bad news in the end.
Can you imagine someone building a house without blueprints? Would you buy that house?
What would happen if everyone on the team followed different ideas about how to do things? What if such as simple thing resulted in losing $327 million dollars? It happened in NASA when a Mars lander crashed because of a lack of standards (and standards checking) (Mars Mission Disaster).
A convention is a common way of doing something. It may or may not be a standard (requirement). For example, hyperlinks on web pages are often blue, and many times they are underlined. That is a convention. Wikipedia only underlines the link when you hover over it. Also a common convention. Conventions are helpful because they are recognized and understood by most people.
Conventions in coding are the same thing. In Python, it is a convention to name a constant in all caps, like
Not all conventions become standards. (As I mentioned above, some projects do not really have standards!).
Standards are a formalized statement of rules. If I code a program for your organization, how am I supposed to write my code? If the organization or project has standards - GREAT! I can simply read and follow the rules, and the next person that looks at my code will be able to easily follow it.
Who is the next person? Does not matter. As coders, we are always coding for the next person. That might be a boss, a peer, a client, or a code reviewer (even an automated one). We do not code for ourselves; we code for other people. Many well-run organizations audit your code automatically. If it violates the standards, it is not accepted and you re-code it until it is right. (You might also get a visit from your boss or the person in charge of code compliance...)
Let's take an example. Here is someone else's code for a simple algorithm. Let's assume the overall program is 1,000 lines:
FinalAmt = UserAmt * p
Here is what I am used to, based on the standard in the organization:
final_amt = user_amt * pct_of_share
One is not immediately more readable than the other, but is it more understandable? If you are not used to reading Pascal Case (the first variable naming for FinalAmt), it becomes much more difficult to read through 1000 or more lines of code to read and understand how all the variable are used. Trying to follow how the variable "p" is used in that 1000+ lines of code is also difficult.
Variable naming (based on standards and/or conventions) is one of the most important things that a coder does. We spend much of our work lives reading and re-reading code; if the names are crappy, our work is crappy. It is a big deal. Here are some people that agree:
More importantly, following the organization or project standards is key to everyone working together.
So this is an introductory course to programming. Why the focus on standards?
Understanding and following standards is a skill needed for coders and developers in ALL languages. It becomes a skill when it becomes a habit (no, not a nun hat):
Because a habit is second nature, it feels uncomfortable when you don't do it.
Developing good coding habits will make you a better coder and better employee later. Employees that cannot follow standards (and don't) understand the importance of them, do not last long.
The habit we want to develop is to follow the standards. Look for them. Adhere to them. Incorporate them into your coding process.
Reasons for Some Course Standards
It is entirely valid to ask why some standards are defined and are important. Here you go:
- File naming (assignments): easier to organize files by Module, Exercise and Student (there are sometimes 100 files to grade for a single assignment)
- Program header: primary usefulness is to identify the programmer and last date edited.
- Using ISO dates (as in the header): The ISO date format (yyyy-mm-dd) is the only universally valid date format. 12/5/2020 means something different in the U.S. and almost everywhere else.
- Space after comment marker (in Python: "#"): Readability. Although comments are normally marked in another color from the main code (green in Notepad++), it still takes time to easily read it without the extra space.
- Variable Naming: basic Python conventions.
- Program banner: common practice. Also requires that every student must code something beyond copying and pasting code from elsewhere.
- Naming constants as all uppercase: Python convention.
- No literals: common practice in all languages. This is less important when code is modularized and created in small methods.
- Number formatting: common practice. Also relieves the need to stipulate specific requirements for every assignment.
- No automatic conversion for input values: Common practice. Except in HTML5 web forms, most languages use a "text" box for input - which returns a string by default. One cannot assume the user will enter valid data.
- Minimmize global variables: Best practice. Easier to maintain and more efficient from a CPU/memory perspective.
- Small methods: Best practice in most languages. It is easier to maintain and troubleshoot modular code.