There are a number of mistakes I see beginners -- and even some experts -- make when it comes to learning to program. They aren't always directly related to any specific language, and I've dropped into these pitfalls more than a few times the past four decades I've been writing code.
So I thought I'm make a sticky outlining said common errors and toss in a few good practices. Anyone has something to add to this, let's hear it.
Editors, wizards, frameworks, and anything that "does the work for you" One of the biggest mistakes early in learning is hoping that your editor or some framework will do all the work for you. Even the simplest of aids and shortcuts can in the long term bite you in the backside for one simple reason:
You're not learning how to actually do anything.
If you have tools doing things for you, what exactly are you learning? If you're just learning, how are you qualified to know if what the tool is doing is right, correct, or how it actually should be done.
You can see this quite plainly on the front-end with frameworks like bootstrap (aka bootcrap), w3.css, blueprint, etc, etc. They make it LOOK easy, and they let you quickly get a result... but whilst that result might look pretty for YOU, they're done incorrectly, are bloated, slow, harder to maintain, harder to customize for things the framework doesn't do out of the box, and more often than not tell users with accessibility needs to sod off.
That last part can get you into deep legal doo-doo depending on the type of site.
In fact, systems like bootstrap are plainly and evidently written by people unqualified to write a single line of HTML and CSS. If you actually
know said languages go to their
examples pages and view-source any of them. If you don't recoil in shock and horror at the train wrecks of incompetence and ineptitude, you don't know as much about HTML as you think.
That's a significant part of how people get suckered into using such trash in the first place. You're a nube, you don't know any better, and letting yourself get duped by these
allegedly "easier" solutions only creates a confirmation bias that will hobble you when it comes time to do things right. There are a
LOT of supposed "experts" and "professionals" out there who use these systems to the exclusion of all other approaches, and to be brutally frank most of them are unqualified to do the job at the business level. Frankly, I doubt that those who adopt said techniques even know enough to do so casually for personal websites.
It is because of this I consider much of the 'automation' out there to fall into the trap of "false simplicity". It is possible to make something look simpler, whilst making doing the actual task harder. When your task is learning to do things, having anyone or anything do it for you means you're not learning!
I personally have to be careful with that, as I'm prone to saying "oh I can do that in three minutes" and just doing it for people.. When I do so though, I at least TRY to document everything so they can learn from it.This said, there are useful tools that if they help go ahead and use, as they are more about helping you keep track than doing things for you. I personally find colour syntax highlighting to be an illegible useless broken mess, but some people find it helpful. That's fine, it's not coding for you, it's a tool to help digest / separate the code. Brace matching is a tool I rely on all the time given how many {[([])]) nests we end up dealing with. Those types of things don't do the work for you, they just make the work easier.
A difference lost upon some...
Don't make excuses, FIX THINGSIt is very easy to start going "well I can fix that later", or "well I haven't learned that yet", or "this isn't part of my audience" or any of a dozen other lame excuses not to do things right. Whilst certainly time constraints can be a legitimate reason to put something off, once you start doing it the whole mess snowballs.
The "I haven't learned that yet" part is particularly frustrating for YOU, because if you're just starting out and learning, falling into that behavior
will stop you from EVER learning it!. It might suck, but buckle down and learn it. If you're having trouble understanding it, come to a forums like this one and ASK.
For great examples of "lame excuses" I always point people at this article:
https://www.456bereastreet.com/archive/200704/lame_excuses_for_not_being_a_web_professional/Whilst over a decade old, most of it is more true today than when it was written!
Whitespace and consistent formatting are your friendWhilst there are a plethora of "style guides" out there, so long as all your code is consistently formatted which one you use shouldn't matter.
Whilst you'll have tons of pointless pedantic arguments over
Spaces vs. Tabs and how wide your tabs are and so forth, or over if an opening { is on the same line as why or wasting a line all to itself, the bottom line is that it shouldn't matter as any decent editor should let you quickly switch between the different styles, and there are tons of "pretty printer" programs out there to reformat existing code however you like.
But again, don't rely on the tools for your own code. Learn to do it a specific way, keep with that way, and be consistent. Good block-level indenting, extra whitespace such as newlines around blocks that feel cramped, can make your code easier to read and digest, and can clearly show the logic blocks.
Whilst excess whitespace in HTML, CSS, and JavaScript can make a page a hair slower, if you have enough whitespace for it to really be an issue in the age of gzipped content delivery handled by the server automatically, you might have a problem; but if it
really matters to you? That's what minification is for. Plenty of tools to strip out excess whitespace and comments for your deployment copy... just don't do that to your development copy!
Learn when and when NOT to commentIt's often painful going into codebases that are unclear through the lack of verbose variable or function names, only to then find a complete lack of comments. At the same time painfully obtuse over-commenting can be just as bad if not worse, as you can't find the actual code in the sea of comments.
Good well written code
SHOULD be self documenting, in that you use variable names that are standard practice
(For example i, j, k for loops in most languages, "e" for a local scope element and 'd' for document in JavaScript) of flat out describe what the variable is, or is for. Same for markup where you should be saying what things ARE.
HTML is a great place to show this as you'll often see bloated stupid commenting like:
<div id="mts_103"><!-- START top section -->
</div><!-- END top section -->
Really, opening a DIV starts a section and closing the DIV ends it?
WHO KNEW?!?. When the tag already says its doing something, don't waste time saying it again in the comment!
Likewise the painfully and pointlessly crypic ID -- the type of which you see all the time -- would make the opening content pointless if the coder had just called it id="topSection"
The only useful comment there is that with the </div> it's often hard to tell WHICH <div> is being closed. I dealt with that a
lot in the SMF skin when giving it this repaint. As such a closing comment can actually help, but keep it simple.
Finally,
and this is a HTML thing comments have been known to cause rendering bugs in IE and FF if it's placed between sibling-level elements. Whilst no longer a major issue when/if this crops up, you'll tear your hair out wondering what's wrong. Easiest way to avoid this is to put your closing comment
before the tag.
Hence what should probably have been written there is:
<div id="topSection">
<!-- #topSection --></div>
Notice also the use of the # to indicate that it's an ID. If you've got a lot of content in such a DIV it's often handy to know that <!-- #topSection.modal --> is what's being closed when the opening tag is off the top of the screen.
These practices can apply to most any language in that a closing comment can save your tuchas. Even something as simple as:
function doNothing() {
} // doNothing
Can work wonders when/if that function grew larger than what fits on the screen... or when trying to figure out where/if you forgot a } or used an extra one. This also plays well with the previous section about formatting habits.
Really if you have to resort to comments for "normal code" there's something wrong. The best time for your content to have a comment is either explaining values that can be changed with impunity (common in JS), or when you are violating a good practice for a good reason.
This article on IBM's Linux developer site whilst meant for C programmers I feel is useful for every skill level of programmer regardless of language used.
https://www.ibm.com/developerworks/library/l-clear-code/index.htmlI'm particularly fond of the "oh, now we're done?" part, since that's exactly what I just described people doing in HTML.
Stick with good practices, until you can't.A lot of developers -- and I've done this myself -- will say "there's no reason for invalid code". ANY rule, no matter how well minded has to have exceptions. This is doubly true if the standards bodies setting the rules go off the deep end like the W3C has been doing the past few years.
Again, HTML is great for examples of these exceptions. Take the media="" attribute on LINK, which says which types of devices should obey said <link>. There used to be a whole bunch of them, but the specification itself said that which ones exist is up to the vendors, not the specification because a new type of device or method of interacting with the web could come along at any time.
Now though? Anything not on a shrunken "approved list" throws a warning in HTML validation. That's utter bullcookies when ones like "projection" (often used by kiosks) and "tv" (MSN TV, Wii, WiiU, DS) still have users in regular circulation. As such when the official HTML 5 validation throws a warning about that, I tell it to kiss off. That's a
legitimate reason in that I'm putting users ahead of what the standards say.
Another example is the recent pointless change so that TFOOT before TBODY is invalid, when in 4 Strict it was the other way around. There was a reason for TFOOT before TBODY, and that reason was for multi-page delivery (print) or summary use, you needed that information so that it could be printed on every page or directly accessed before the content even finished downloading.
IF they had loosened the rule becuase the number of people using TFOOT properly could be counted on one hand, I'd be fine with it. But now throwing an ERROR
(not even a warning) for all the people who actually understood it and used it right? That's just BS and makes me ignore that error.
Now, whilst I just listed some examples of when to ignore it, it becomes too easy to take that attitude with everything. Some changes -- like those in PHP -- are done for very good reasons, and throwing a hissy fit "wah wah, I don't wanna use prepare/execute" is not how you should handle things.
There are many more esoteric cases -- like the invalid browser prefix stuff in CSS -- that are necessary but incorrect. It's just the nature of the beast and it's why CSS validation is basically a joke at this point.
THAT DOESN'T MEAN YOU DON'T TRY!!!. Try as much as possible to have valid/proper code... and if you are blatantly, fraglantly, and wantonly violating the rules, take the time to toss in a comment to explaini WHY!
You can't remember every little detail, use a quality reference!When learning to program it's often essential to learn what can be done, but it is impossible for everyone to remember everything all the time. Get a quality reference (PHP.NET, MDN), and learn how to search and navigate it. This seems obvious, but from the questions that often pop up on development forums? Well... there's a reason some
tubby snobs constantly belt out "RTFM".That's an attitude some of us greybeards need to keep in our pants. The idea that someone went through the effort of registering for a forum, following the confirmation e-mail, and creating a post without having first at least tried google? Land's sake Google is probably what brought them to the forum! They're nubes, they might not even know the correct terminology to search for.You can't know it all, you can't remember it all, so if in doubt, go to the reference. If the reference fails you, come someplace like this and ASK.
There is no shame in not knowing something; this is why I don't consider the word "ignorant" to be an insult. It just means you don't know. You can fix ignorant.
Though as Ron White said, "you can't fix stupid."Just beware there are some references/sites that are horribly outdated, blatantly incorrect, filled with bad practices, or trying to dupe you into thinking they are some sort of official site when they aren't, and offering rubbish "certifications" that mean exactly two things; and Jack left town. Some -- like W3Schools -- are all of the above. Learning to separate the wheat from the chaff, and telling what's a scam and what isn't is as important a part of the learning process as the underlying languages themselves.
Watch out for bandwagon and other propagandaJust because something is popular doesn't make it good, or right. This is the number one fallacy you'll come across in the learning process. There are those who will try to convince you to do something just because it's what everyone else is doing. That is NEVER sufficient justification for anything.
Likewise beware of card stacked "results". Sometimes things -- vue, react, and bootstrap for example -- will cherry pick corner cases, or use outright bad code to compare theirs to as justification for why they are "better". This is most always complete nonsense and is a warning flag you should learn to recognize.
The glittering generality of saying something is "easier" without saying "
WHY?!?" has become painfully common in the industry, and like all the other propaganda techniques it's more meant to make you feel instead of actually thinking.
There are seven propaganda techniques:
- Bandwagon
- Card Stacking
- Glittering Generalities
- Name Calling
- Plain Folks
- Testimonial
- Transfer
Learn them, recognize them when they are used, and then try to figure out the intent of why they are being used. When you're doing something new, the wolves are out there and they will use these techniques to try and take advantage of you.
There is no end to the learningA lot of people will try to treat programming as a "learn it once and you're set for life"; or worse teach it as such. This is another fallacy. As a dearly departed friend of mine once said:
The day you stop learning is the day the rest of the world leaves you behind.
There is always a new technology, a new trend, changes to the security landscape, improvements in technique, and just plain better ways of doing things. If you try to coast at any point on your existing knowledge, you might as well just stop altogether.
I've been programming for near-on four decades, and of the knowledge I had just a decade ago I'd say a third belongs on the trash heap and forgotten. That is just the nature of the beast. Get used to it. If you do not have that deep-rooted love of learning, this is
not the field for you.
See how much use I'm getting out of my mastery of ADA at the moment. That was sarcasm.It is to that end -- the ever changing nature of coding practices -- that if you aren't disgusted with your own code of just a year past, you might want to re-evaluate your skills and go do some research.
The best developers I've ever known have been the ones who can evolve, change, and adapt with the ever-changing technologies. Computers are a field where on the hardware side 3 years is obsolete, five years is the scrap-heap.
AT BEST you can only expect about double those numbers on the software side.
So... hopefully someone finds this helpful. It's not the stuff usually discussed but I really feel it's an important starting place for all developers to have this base notion of what's really involved... Much less where things can go pear-shaped.