From the definition of naive, naive programming isn't necessarily bad programming; it just shows that the person writing the code lacks experience, judgement, or wisdom. In many cases naive programming produces code that is just slower than what a more experienced programmer might right, but sometimes the naive code fails miserably.

Suppose you write code to get the month, day, and year to put in a report that you're about to generate and to use as part of the filename for that report. That could naively be done with:

Code:

YYYY=$(date +%Y)
MM=$(date +%m)
DD=$(date +%d)
label="$MM/$DD/$YYYY"
filename="report_${YYYY}_${MM}_${DD}.txt"
...

A more experienced programmer might do the same thing with:

Code:

IAm=${0##*/}
read label filename hour <<-EOF
	$(date '+%m/%d/%Y report_%Y_%m_%d.txt %h')
EOF
if [ ${hour#0} -lt 8 ]
then	printf '%s: This program should not be run before 8am.\n' "$IAm" >&2
	exit 1
fi
...

If you run this program every day at noon, will the label and filename variables be set differently with these code segments? Almost certainly, no.

If you run this program every day in a cron job scheduled to run at one minute before midnight what values might you get for those variables on December 31, 2016 when lots of long-running month-end and year-end reports are running at the same time? With the naive code you could get any one of the following four sets of values for those variables:

Code:

label		filename
==========	========
12/31/2016	report_2016_12_31
12/01/2016	report_2016_12_01
01/01/2016	report_2016_01_01
01/01/2017	report_2017_01_01

Note that the middle two of those will overwrite daily reports from the start of the previous month or year and the last one will be overwritten by the report written at the end of the day on January 1st (unless the mistake is caught sometime during the day on New Year's day). With the more experienced programmer's code, the last three will never happen, but you might get a diagnostic message instead of the wanted report if the code is started late. When the naive programmer is bitten by this, (s)he learns from experience that the code needs to be made more robust and becomes less naive (and learns that you shouldn't schedule cron jobs to run at one minute before midnight if the code that will be run depends on being run before midnight).

Note that naive code can sometimes run faster than well written code, but fail miserably when unexpected (and unchecked) events occur.

Most of the code we write in this forum assumes that data is in the specified format and skips a lot of error checking that should appear in production code. Many of us should be more careful to point out that the sample code we suggest here should be strengthened with appropriate error checking if the code is going to be used in a production environment.