not so good code/examples

Diputs

Active Member
Joined
Jul 28, 2021
Messages
194
Reaction score
78
Credits
1,471
Daily I see examples of bad code and commands and I was wondering where on this forum it would be a good place to post this kind of examples, explaining why they are a bad idea.
 


This forum I feel would suite best, start with a short blog as to your thoughts and intentions and remember to invite other members to join in. Be prepared for other members to disagree as some commands are not always bad but just distribution specific.
 
Daily I see examples of bad code and commands and I was wondering where on this forum it would be a good place to post this kind of examples, explaining why they are a bad idea.
Every piece of code is bad in the eyes of a pedantic coder.

I consider myself pedantic, when ever I clone something from GitHub the very first thing I do is fixing bad formatting, syntax errors, build errors or what ever other stuff that I don't like.

The code might be functional and quality made, but very rarely I find it readable or pleasant for my eye or coding styles.

It's just something you have to accept.
Either you continue writing bad code or otherwise reinvent the wheel and do it all from scratch to be happy.
 
Every piece of code is bad in the eyes of a pedantic coder.

I consider myself pedantic, when ever I clone something from GitHub the very first thing I do is fixing bad formatting, syntax errors, build errors or what ever other stuff that I don't like.

The code might be functional and quality made, but very rarely I find it readable or pleasant for my eye or coding styles.

It's just something you have to accept.
Either you continue writing bad code or otherwise reinvent the wheel and do it all from scratch to be happy.
I have to agree.
Accuracy and precision are an essential key to writing code. Details are so important!

My take is if you are going to do it, it should be done right the first time. That way, the process/procedure won't have to be repeated again....thus wasting time you could have spent doing something else that would produce positive results.

Learning to do things well and correctly with certainty has saved me from future headaches.
 
@Alexzee
Linus Torvalds once said that bad coders care about the code while good coders care about data structures.
And I disagree with him, no wonder Linux kernel is so hard to understand and to read with his programming logic.

He writes quality code, but where are the people willing to read it and contribute?
 
The "code" I refer to is more related to command line usage, not entire source code of the Linux Kernel

Things like this:

For clarity : DO NOT RUN THIS COMMAND !

cd /some/path ; rm -rf *


For clarity : DO NOT RUN THIS COMMAND !
 
Last edited by a moderator:
@Alexzee
Linus Torvalds once said that bad coders care about the code while good coders care about data structures.
And I disagree with him, no wonder Linux kernel is so hard to understand and to read with his programming logic.

He writes quality code, but where are the people willing to read it and contribute?
Willing to read it and contribute is part of my summer project.
 
The "code" I refer to is more related to command line usage, not entire source code of the Linux Kernel

Things like this:

cd /some/path ; rm -rf *
Got it-
Running commands is natural to us that use Linux everyday. Certain commands (depending on what you need to run) can be lengthy and require the right command-line argument.

Explaining why they are a bad idea is good.

I wrote an article about using wisdom when using the command-line.
 
Using cat and grep together is probably one of the most common things I see:
E.g.
Bash:
cat /path/to/file | grep whatever

There’s no need for cat. Just use grep:
Bash:
grep whatever /path/to/file
 
Using cat and grep together is probably one of the most common things I see:
E.g.
Bash:
cat /path/to/file | grep whatever

There’s no need for cat. Just use grep:
Bash:
grep whatever /path/to/file

I am so guilty of that.
 
That's a classic indeed

This is also something I see:

cd /some/directory ; unzip /source/file.zip -d .

or also

cd /source ; unzip file.zip -d /some/directory

You could say it's a combined navigation (CD) and extract (unzip) action, but then NO other command follows that needs the navigation. So, the CD command is totally unnecessary.

Or also :

cd /some/directory ; unzip /source/file.zip
 
Last edited:
Using cat and grep together is probably one of the most common things I see:
E.g.
Bash:
cat /path/to/file | grep whatever

There’s no need for cat. Just use grep:
Bash:
grep whatever /path/to/file

Well, there can be a reason, like this:

cat -v word file.txt | grep whatever

The CAT command may have optional features that GREP won't be able to provide, but this is very specific all right.
 
Last edited:
I worked with a system engineer once and he prefixed all Linux commands with the full path, in every script, like this:

/usr/bin/cp sourcefile.txt targetfile.txt

Seemed excessive to me, but I can see a point
 
Found something bad as well:

A script was written and placed into Crontab, which performs a certain backup, BUT it also cleans up old backups of the same backup action he also runs as well. Nothing wrong, you'd think.
Well, the Crontab job can be disabled - like any Crontab job really - but when you do this, this is what happens :
No new backups are written, good. But, no cleanup is occuring either. So, if you leave this job disabled for 2 years, you will have old backups sitting there for 2 years, wasting space, because these backups are useless given the age. The Crontab job is disabled for reason of not needing new backups, so old backups are unnecessary in this context. If these old backups are important, it's never intended as such, because these old backups can just be removed by running the script. Not as a Crontab job, but just as a script. Ironically, that would be to create a new backup. Becasuse, at some point you'd want to. But, this comes with the price that all old backups are deleted. Nobody ever had many thought about this script. They wrote it. yes it works, so now never change it, whatever happens !

In addition, what seems to be the case as well: the backup done via the script, can fail.
But, the cleanup occurs unconditionally.
 


Top