Freethought & Rationalism Archive

DNAunion · 07-08-2003, 07:47 PM

DNAunion: I was doing a little light reading the other night and ran across something interesting. The following quotes should speak for themselves (but hey, I�ll comment anyway).

Quote:

�Good Programming Practice 7.1
Strive for program clarity. It is sometimes worthwhile to trade off the most efficient use of memory or processor time for writing clearer programs.� (bold and italics in original, H. M. Deitel, P. J. Deitel, J. A. Listfield, T. R. Nieto, C. H Yaeger, & M. Zlatkina, C#: A Programmer�s Introduction, Prentice Hall, 2003,p208)

DNAunion: Now where have I heard that before? Oh yeah, I said it.

That settles that. But it also inspired me to dig a bit for more quotes on this general topic.

So the next question is, is it really an error to use a little redundancy in order to improve the clarity of source code, as [somebody] asserted? Nah.

Quote:

�As in algebra, it is acceptable to place unnecessary parentheses in an expression to make the expression easier to read. Unnecessary parentheses are also called redundant parentheses. For example, the preceding assignment statement might be parenthesized as

Code:

	y = ( a * x * x ) + ( b * x ) + c;

Good Programming Practice 3.13
Using parentheses for more complex arithmetic expressions, even when the parentheses are not necessary, can make the arithmetic expressions easier to read.� (bold and italics in original, H. M. Deitel, P. J. Deitel, J. A. Listfield, T. R. Nieto, C. H Yaeger, & M. Zlatkina, C#: A Programmer�s Introduction, Prentice Hall, 2003,p63)

DNAunion: That�s one. Surely it�s the only one�right? No.

Quote:

�Note that it is not necessary to use braces in the do/while structure if there is only one statement in the body. However, the braces normally are included to avoid confusion between the while and do/while structures. For example,

Code:

	while ( condition )

typically is the header to a while structure. A do/while with no braces around the single statement body appears as

Code:

	do
		statement;
	while ( condition );

which can be confusing. The last line � while (condition ); � might be misinterpreted by the reader as a while structure containing an empty statement (the semicolon itself). Thus, the do/while with one statement often is written as follows to avoid confusion:

Code:

	do
	{
		statement;
	} while ( condition );

Good Programming Practice 5.9
Some programmers always include braces in a do/while structure, even when the braces are unnecessary. This helps eliminate ambiguity between a while structure and a do/while strcuture that contains only one statement.� (bold and italics in original, H. M. Deitel, P. J. Deitel, J. A. Listfield, T. R. Nieto, C. H Yaeger, & M. Zlatkina, C#: A Programmer�s Introduction, Prentice Hall, 2003,p129-130)

DNAunion: The same �authors� (Deitel & Deitel) have a 2003 book on ANSI Standard C++, and in it, they give another example.

Quote:

�Software Engineering Observartion 10.2
Once a function is declared virtual, it remains virtual all the way down the inheritance hierarchy from that point, even if that function is not explicitly declared virtual when a class overrides it.

Good Programming Practice 10.1
Even though certain functions are implicitly virtual because of a declaration made higher in the class hierarchy, explicitly declare these functions virtual at every level of the hierarchy to promote program clarity." (bold and italics in original, H. M. Deitel & P. J. Deitel, C++ How To Program: Fourth Edition, Prentice Hall, 2003, p674)

DNAunion: They state that a base class�s virtual function (a member function that is able to be overridden by a derived class) remains virtual all the way down an inheritance chain and so needs to be qualified as virtual only once. However, they recommend as a �Good Programming Practice� that each derived class also explicitly specify the function as virtual, even though doing so in unnecessary, in order to improve code clarity.

In that same text, the authors state:

Quote:

�Good Programming Practice 2.20
In a switch structure that lists the default clause last, the default clause does not require a break statement. Some programmers include the break for clarity and symmetry with other cases.� (bold and italics in original, H. M. Deitel & P. J. Deitel, C++ How To Program: Fourth Edition, Prentice Hall, 2003, p119)

DNAunion: Let�s face it, code readability and clarity are considered important goals in the programming world. And, tradeoffs � such as introducing slight redundancy, using a few more CPU cycles than required, using up several extra bytes of memory, etc. � are frequently made in order to promote those goals, AS PART OF GOOD PROGRAMMING PRACTICES.

Next.

Now, what was that [somebody] said about the if statement being spaghetti code?????

Quote:

�During the 1960s, it became clear that the indiscriminate use of transfers of control was causing difficulty for software development groups. The problem was the goto statement, which, in some programming languages, allows the programmer to specify a transfer of control to one of a wide range of possible destinations in a program. This caused programs to become quite unstructured and hard to follow. The notion of structured programming became almost synonymous with �goto elimination.�

The research by Bohm and Jacopini demonstrated that all programs with goto statements could be written without them. The challenge of the era for programmers was to shift their styles to �goto-less programming.� It was not until the 1970s that programmers started taking structured programming seriously. �

Bohm and Jacopini�s work demonstrated that all programs could be written in terms of only three control structures, namely, the sequence structure, the selection structure and the repetition structure.

�

C# provides three types of selection structures, which we discuss in this chapter and the next. The if selection structure performs (selects) an action if a condition is true or skips the action if the condition is false. The if/else selection structure performs an action if a condition is true and performs a different action if the condition is false. The switch selection structure, discussed in Chapter 5, Control Structures: Part 2, performs one of many actions, depending on the value of an expression.� (bold and italics in original, H. M. Deitel, P. J. Deitel, J. A. Listfield, T. R. Nieto, C. H Yaeger, & M. Zlatkina, C#: A Programmer�s Introduction, Prentice Hall, 2003,p74-75)

DNAunion: Followed by a discussion of C#�s if and if/else structures on pages 76-82.

Let�s see. The goto/spaghetti-code crisis existed back in the 60s and 70s, and it was during the 70s that structured programming began taking hold as a means of eliminating such confusing code. Why in the world, then, would a brand-spanking new language like C# include the if structure if it is itself, as alleged-by-[somebody], �spaghetti code�? And why devote 5 or 6 pages to if if it is itself, as alleged-by-[somebody], �spaghetti code�? That�s a real puzzler, ain�t it???

Note also that two out of C#�s three selection structures are �if�s�.

Worse yet, the third C# selection structure, switch, has pretty limited flexibility/applicability and therefore cannot substitute for �if�s� in a vast many situations. However, the opposite is not true: that is, anything that a switch can do can be recoded using if (as can any if/else logic). Therefore, contrary to what [somebody] would have us believe, if is the fundamental selection construct of structured programming.

And it�s not just C#. All major programming languages � Visual Basic and VBA and VB Script, Visual C++ as well as ANSI standard C++, C and PHP, Java and J++, Visual FoxPro, etc. � include the if selection mechanism, and it plays a pivotal role in each.

If is clearly here to stay � it�s not about to be deprecated.

Quote:

�In summary, structured programming promotes simplicity. Bohm and Jacopini have found that only three forms of control are necessary:

sequence
selection
repetition

Sequence is trivial. Selection is implemented in one of three ways:

if structure (single selection)
if/else structure (double selection)
switch structure (multiple selection)

If fact, it is straightforward to prove that the if structure is sufficient to provide any form of selection. �

Combining these results illustrates that any form of control ever needed in a C# program can be expressed in terms of

sequence
if structure (selection)
while structure (repetition) �

(bold and italics in original, H. M. Deitel, P. J. Deitel, J. A. Listfield, T. R. Nieto, C. H Yaeger, & M. Zlatkina, C#: A Programmer�s Introduction, Prentice Hall, 2003,p141-143)

DNAunion: Wow, that if structure sure is important to structured programming.

How about another one.

Quote:

�Figure 2.3 illustrates the single-selection if structure. This [UML] activity diagram contains what is perhaps the most important symbol in an activity diagram � the diamond or decision symbol, which indicates that a decision is to be made.� (bold and italics in original, H. M. Deitel & P. J. Deitel, C++ How To Program: Fourth Edition, Prentice Hall, 2003, p76)

DNAunion: Hmmmm�.looks like if is pretty fundamental to modern-day computer programming after all�quite contrary to the position [somebody] expressed.

Asha'man · 07-09-2003, 04:46 AM

A couple of notes:

There is a vast difference between compile-time efficiency and run-time efficiency. Adding a redundant paren has no effect on run-time performance, and a virtually unmeasurable effect at compile-time. On the other hand, an extra paren may save hours of developer-time.

I don't see where the if statement is claimed to lead to spagetti code. Where exactly are you reading that?

Principia · 07-09-2003, 05:55 AM

Quote:

Asha'man: There is a vast difference between compile-time efficiency and run-time efficiency. Adding a redundant paren has no effect on run-time performance, and a virtually unmeasurable effect at compile-time. On the other hand, an extra paren may save hours of developer-time.

Right on, dude!

Quote:

I don't see where the if statement is claimed to lead to spagetti code. Where exactly are you reading that?

Actually, excessive and undisciplined use of the if statement can lead to spaghetti code. One has to remember that spaghetti code does not necessarily entail usage of GOTO statements. For example, read here:

Quote:

Spaghetti code is a pejorative term for code with a complex and tangled control structure, especially one using many GOTOs, exceptions, or other "unstructured" branching constructs. It is named after spaghetti because a diagram of program flow tends to look like that. Nowadays it is preferable to use so-called structured programming.

Also called kangaroo code because such code has so many jumps in it.

Let's have a lecture page from MIT's intro to computer science course, give us an example:

Code:

Symbolic Derivative - Spaghetti Code
(define (deriv exp var)
(cond ((number? exp) 0)
	((symbol? exp)
	(if (and (symbol? var) (eq? exp var))
	 1
	 0))
	((and (pair? exp) (eq? (car exp) �+))
	 (list �+
	 	(deriv (cadr exp) var)
		(deriv (caddr exp) var)))
	((and (pair? exp) (eq? (car exp) �*))
	 (list �+
		(list �* (cadr exp)
			(deriv (caddr exp) var))
		(list �* (deriv (caddr exp) var)
			(caddr exp))))))

For those who do not know Scheme/LISP, cond is the equivalent of if/switch-else in C based languages. Similarly, pair? and eq? are also conditional keywords. So within this little code, there is 3 nested levels of conditionals, with recursion to boot. This code, while "structured," is inherently spaghetti. It is inherently difficult to understand the flow of the program. Let me give another example of spaghetti code, in a more familiar language:

Code:

if (x == 1)
{
  if (y == 1 && x > 0)
  {
     if (x > 2 || y < 2)
        printf("Hello world.\n");
     else if (y < 3)
        printf("Goodbye world.\n");
  } else {
     if (y < 3)
        if (x == 0)
          printf("Where am I?\n");
       else
          break;
  }
}
else if (z == 2)
{
   printf("Now I'm really confused.\n");
   if (x == 1)
   {
      printf("But didn't we just test for this above?\n");
      if (x < 0)
        printf("Whaa...??\n");   
   }
}

On the same token, GOTO statements do not automatically imply "unstructured code." For instance, consider this homework set, again from an MIT computer science course:

Quote:

This section will list clarifications and answers to common questions about problem sets. We'll try to keep it as up-to-date as possible, so this should be the first place to look (after carefully rereading the problem set handout and the specifications) when you have a problem.
Question: In Problem 2, is it really wise to use a labelled continue statement? Isn't this like the evil goto statement in other languages, which leads to "spaghetti code"?
Answer:

Jumps and branching statements (continue, exit, return, exceptions) in Java are not the same as in other languages (goto). See the Java Language Specification on Blocks and Statements. Or, see information on Unconditional Branch, which states that "Java only allows structured flow-control statements to be used and therefore does not support the Unconditional Branch."
Non-local jumps (exceptions) are very powerful and discussed at length in Daniel Jackson's lecture on exceptions, found in the site archives (Fall 2000, Lecture 4: Exceptions).
Continue and exit often improve the structure of the code, certainly much better than adding lots of flags, which makes a program incomprehensible and often less efficient.
Read Go To Statement Considered Harmful, Edsger W. Dijkstra, and then the rebuttal by Donald Knuth, Structured Programming with go to Statements, ACM Computing Surveys, 6(4):261--301, December 1974.
See arguments against and for GOTOs, along with some code examples.
Java Developer Connection (JDC) has a tip on GOTO Statements and Java Programming, which has code comparisons between C++ (using goto) and Java (using labeled blocks).

Let me especially quote from the pro arguments, cited above:

Quote:

The argument for the goto is characterized by advocating its use in specific circumstances rather than its indiscriminate use. Most arguments against gotos are based on indiscriminate use, rather than careful use. The goto controversy began when Fortran was the most popular language. Fortran lacked any presentable loop structures, and, in the absence of any good advice on programming structured loops with gotos, programmers wrote a lot of spaghetti code. Such code undoubtedly was correlated with low quality programs but has little to do with careful use of a goto to make up for a gap in a structured language's capabilities.

A well-placed goto can eliminate duplicate code. Duplicate code leads to problems with the two sets of code being modified differently. It increases the size of source and executable files. The bad effect of the goto is outweighed in such a case by the worse effect of duplicate code.

The gotos is useful in a routine that allocates resources, performs operations on those resources, then deallocates the resources. With gotos, you can cleanup in one section of code, and they reduce the danger of forgetting to deallocate the resources in each place you detect an error.

In some cases, gotos can result in faster and smaller code. Knuth's marvelous 1974 article cited a few cases in which gotos produce a legitimate gain (Knuth 1974).

Good programming doesn't mean eliminating gotos. Methodical decomposition, refinement, and selection of control structures automatically leads to goto-free programs in most cases. gotolessness is not the aim, but the outcome, and putting the focus on no gotos isn't helpful.

[Now where was this helpful advice in DNAunion's list above?

-- Principia]

Two decades worth of research with gotos has been inconclusive in demonstrating their badness. In a survey of the literature, B. A. Sheil concluded that unrealistic test conditions, poor data analysis, and inconclusive results failed to support the claim that the number of bugs was proportional to the number of gotos (Sheil 1981). That criticism applies to Shneiderman's survey of the literature, cited in the argument against gotos, as well as other studies. Sheil did not conclude that gotos were good, rather that experimental evidence against them was not conclusive.

Finally, goto was included as part of the Ada language, the most carefully engineered programming language in history. Ada was developed long after both sides of the goto debate were fully developed, and, after considering all sides of the issue, included the goto.

DNAunion · 07-09-2003, 06:03 AM

Quote:

DNAunion: I didn't see any GOTOs or other indicators of spaghetti code in my programs. Can you point them out for us?

Quote:

[somebody�]: LOL. Every if statement you have is a branching code that does 2 things in the compiled code:
1) it does a test
2) it jumps to the right code (and provides a return address for when this code finishes)
Need I remind DNAunion that both C and FoxPro are higher level languages?" (http://www.iidb.org/vbb/showthread.p...i&pagenumber=3)

DNAunion: See, [somebody] claimed that if itself was inherently "spaghetti-ish". How wrong could one person be.

Quote:

[somebody]: Let's take a look at [your] spaghetti code:

Code:

nFoundOne = 0;
while (nFoundOne == 0)
{
	nIndex = (int) GetRandomNumber(0, nLetteredTiles - 1);
	if (nDiscardTilesOnceChosen == 0)
	{
		// Doesn't matter if the tile has been 
		// chosen previously because selected
		// tiles are placed back into the urn.
		nFoundOne = 1;
	}
	else if (cUrn[nIndex][2] == 'T')
	{
		// This tile has already been chosen and
		// discarded: it can't be selected again.
		nFoundOne = 0;
	}
	else if (cUrn[nIndex][2] == 'F')
	{
		// This tile has not been chosen previously.
		nFoundOne = 1;
	}
}

So three if-else if blocks, three implicit branch commands. � Shall we continue with the critique of DNAunion's code? Well, let's see .

PS: A definition of spaghetti code:
************************************************** *
Spaghetti code is a pejorative term for code with a complex and tangled control structure, especially one using many GOTOs, exceptions, or other "unstructured" branching constructs. Nowadays it is preferable to use so-called structured programming.
************************************************** *

(http://www.iidb.org/vbb/showthread.p...i&pagenumber=3)

DNAunion: And here [somebody] mistakes the fundamental selection structure in structured programming -- i.e., if -- with unstructured branching constructs.

PS: I should point out that while grabbing the above quote I just looked at my hastily written C++ code for the first time in weeks and immediately noticed a problem. Although I did remember to convert from 1-based arrays in VFP (the original language the program was written in) to 0-based arrays in C++ (the second language) during my quick conversion (which spanned only an hour or so, while posting simultaneously at 3 boards), I didn�t do so for all indices. Now there's an oversight...but it took me to find it!

PPS: That mistake does not have any negative impact on the accuracy of the program's results...as both my and [somebody's] runs demonstrated. I wonder if [somebody] could explain to us why?

Principia · 07-09-2003, 06:23 AM

Now for my rebuttal of DNAunion's strawman attack.

If anyone is wondering where this thread is coming from, it is here:
http://www.iidb.org/vbb/showthread.p...5&pagenumber=1

In that thread, I demonstrated convincingly that DNAunion is a novice programmer, before the moderators shut down the thread for DNAunion's tantrums. It seems like, 4 months later, DNAunion still has a grudge, and wants to relive that thread. So I shall oblige.

In his first section, DNAunion complains:

Quote:

So the next question is, is it really an error to use a little redundancy in order to improve the clarity of source code, as [somebody] asserted? Nah. [...] Let�s face it, code readability and clarity are considered important goals in the programming world. And, tradeoffs � such as introducing slight redundancy, using a few more CPU cycles than required, using up several extra bytes of memory, etc. � are frequently made in order to promote those goals, AS PART OF GOOD PROGRAMMING PRACTICES.

So what exactly is DNAunion trying to excuse himself, from? Well, could it be this little gem that he wrote?

Code:

long GetRandomNumber(int nMin, int nMax)
{
	long lRandomNumber;

	lRandomNumber = rand();
	while (lRandomNumber < nMin || lRandomNumber > nMax)
	{
		lRandomNumber = rand();
	}
	return lRandomNumber;
}

Notice that to a trained eye, what DNAunion is trying to do here is generate a uniform random number between nMin and nMax, by discarding all the numbers randomly generated between 0 and MAXRANDOM (or whatever the largest integer rand() returns is). This is not the only problem. As I noted then, DNAunion has no clue how to generate uniform random numbers in general (botching up the modulus algorithm):

Quote:

The problem is even worse, since when you take the modulus of FLOOR(RAND()*1000) by lnMax, which is typically not a factor of 1000 (or 1000 and RANDmax), then once again your distribution is biased. There are some numbers that are underepresented. Let me give an example: say I take 0 to 100 modulo 7. There are 15 0's 15 1's and 15 2's whereas all the rest have 14 numbers to them. This is a clear bias.

Or perhaps it is this other gem:

Code:

	for (nTrial = 1; nTrial <= nTrialsPerIteration; nTrial++)
		{

			// Pull a single tile out of the urn
			nFoundOne = 0;
			while (nFoundOne == 0)
			{
				nIndex = (int) GetRandomNumber(0, nLetteredTiles - 1);
				if (nDiscardTilesOnceChosen == 0)
				{
					// Doesn't matter if the tile has been 
					// chosen previously because selected
					// tiles are placed back into the urn.
					nFoundOne = 1;
				}
				else if (cUrn[nIndex][2] == 'T')
				{
					// This tile has already been chosen and
					// discarded: it can't be selected again.
					nFoundOne = 0;
				}
				else if (cUrn[nIndex][2] == 'F')
				{
					// This tile has not been chosen previously.
					nFoundOne = 1;
				}
			}
			// A tile has been chosen: flag it as such
			cUrn[nIndex][2] = 'T';

			// Does the chosen tile match one of the targets?
			if (cUrn[nIndex][3] == 'T')
			{
				nMatches += 1;
			}

			// No need to continue pulling tiles for this iteration
			// if we've obtained enough matches for success
			if (nMatches >= nMatchesNeededForSuccess)
			{
				nTrial = nTrialsPerIteration + 1;
			}
		}

Once again to the trained eye, compare this code to the examples of undisciplined use of if statements, I listed in the post above (with modifications to better match the comparison):

Code:

if (x == 1)
{
  if (y == 1 && x > 0)
  {
     if (x > 2 || y < 2)
     {
        x=0;
        y=0;
        printf("Hello world.\n");
     }
     else if (y < 3)
        printf("Goodbye world.\n");
  } else {
     if (y < 3)
        if (x == 0)
          printf("Where am I?\n");
       else
       {
          x = 2;
          break;
       }
  }
}
else if (z == 2)
{
   printf("Now I'm really confused.\n");
   if (x == 1)
   {
      printf("But didn't we just test for this above?\n");
      if (x < 0)
        printf("Whaa...??\n");   
   }
}

Remember the key notion in spaghetti code is the confusing control flow of the code. In my analysis on the previous thread, I said (and here DNAunion dishonestly deletes the following section when he cites the same quotes in his post above):

Quote:

Let me point out that here, the test (nDiscardTilesOnceChosen == 0) is always satisfied, so the then block is never reached. Let me also point out that the 1st elseif is irrelevant, since its action to set nFoundOne to 0 is redundant (i.e. nFoundOne would have to be 0 to get there anyways). Shall we continue with the critique of DNAunion's code? Well, let's see.

)

Later in the discussion, DNAunion's poor grasp of basic algorithmic structures becomes even more apparent when he says:

Quote:

DNAunion:

Quote:

1) It�s a only 14 characters and took me only about 2 seconds to type (and as the programmer, I get to decide whether to sacrifice clarity to save 2 seconds worth of typing)

2) The code does not become �fatware� simply because I added something like 14 bytes to it

Me: LOL, counting characters to determine computational complexity. That's good. Why I guess I can add this somewhere to your code:

Code:

 while (1==1);

and that wouldn't make it "fatware" at all. After all it's only 14 characters too.

So what is DNAunion doing on this thread? Well, I as commented earlier, it is to establish strawmen, and to rebuild his image as a programmer. For instance:

Quote:

DNAunion: They state that a base class�s virtual function (a member function that is able to be overridden by a derived class) remains virtual all the way down an inheritance chain and so needs to be qualified as virtual only once. However, they recommend as a �Good Programming Practice� that each derived class also explicitly specify the function as virtual, even though doing so in unnecessary, in order to improve code clarity.

Did DNAunion use inheritance structures in his C++ code? Nope. But doesn't it sound like he just figured out that inheritance chains are a good programming practice? I guess he has much more to learn. Also, DNAunion needs to be more honest. Putting words in other people's mouth is dishonest. For instance, I challenge anyone to show where I explictly said what DNAunion says I did -- namely that all if statements lead to spaghetti code. Nope, I guess not. But this is no different when he purposefully dwelled on my not knowing C vs. C++ (I'll leave the readers to judge that for themselves

:

Quote:

Me: Actually, my point 4 was supposed to show that a monte carlo analysis was completely redundant for the problem you are solving... much less having to do it in Visual Foxpro. So, really, that you can program in C neither impresses me, nor does it address the overall theme of my post.

DNAunion: It wasn't C, it was C++. You do know that they are different, right?
DNAunion: You don't know the difference between C and C++.
DNAunion: Principia showed his ignorance of progamming when he incorrectly refered to the language as C instead of C++.
DNAunion: Can you tell us the difference between a C and a C++ program?

So in the quote above, I suggested that DNAunion's knowing C didn't impress me. He launches an attack on my supposed ignorance of C vs. C++. But his attack obviously backfired. Is DNAunion really saying that because he knows C++ (as he claims), he doesn't know C??? I guess if he's so sure I'm wrong in my statement above, that would have to be true.

In that case, I gladly withdraw the implication that DNAunion knows any C.

Quote:

Wow, that if structure sure is important to structured programming.

Having programming experience is important to strctured programming. Having some mathematics skill is also important to understanding programming. DNAunion clearly has neither -- if you want evidence, just read the original thread. I'm content to let DNAunion have the last word on this matter to whoever thinks he has any credibility left.

Moderators, don't worry about me.

DNAunion · 07-09-2003, 06:41 AM

Quote:

Principia: Now for my rebuttal of DNAunion's strawman attack.

DNAunion: Tsk tsk...going for the personal jabs already Principia? Can't beat me legitimately...so sad.

Quote:

Principia: In that thread, I demonstrated convincingly that DNAunion is a novice programmer...

DNAunion: Only to people dumb enough to believe your arguments based on ignorance...you know, like if itself is "spaghetti code". LOL.

Sorry my dear old friend, but I have to go to work now. The rest of your easliy refuted statements will get to go unchallenged for a few hours. Now's the time for you to run for the hills and stop embarrassing yourself!

NialScorva · 07-09-2003, 08:16 AM

"Good programming practices" lists are almost always a list of results from good practices, not ways to achieve good practices. Removing gotos won't necessarily make your program any better, but a good program will contain fewer gotos. The single biggest problem with "how to program" guides is that they rarely understand this. Most of them are books that say "sometimes you need to sacrifice horsepower for emissions standards" and "Don't attach doors with wire, use hinges and weld them on", then claiming to be a book on building a car from the ground up.

Mageth · 07-09-2003, 08:58 AM

PPS: That mistake does not have any negative impact on the accuracy of the program's results...as both my and [somebody's] runs demonstrated. I wonder if [somebody] could explain to us why?

Blind luck?

Jesse · 07-09-2003, 09:19 AM

Principia:
Now for my rebuttal of DNAunion's strawman attack.

DNAunion:
Tsk tsk...going for the personal jabs already Principia? Can't beat me legitimately...so sad.

"Strawman" is an attack on a person's argument, not on the person themselves, so it's not against the rules. But a number of Principia's other comments involved statements about DNAunion's motives, honesty, etc., and those are definitely not appropriate here. Principia, please either avoid these types of personal attacks in your posts, or don't post on this thread at all.

Lobstrosity · 07-09-2003, 09:55 AM

Speaking of "good" programming practices, I find one can learn quite a lot from this site.

Here are a few excerpts I thought were rather enjoyable:

Quote:

A.C.R.O.N.Y.M.S.: Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.

Quote:

Bedazzling Names: Choose variable names with irrelevant emotional connotation. e.g.:

marypoppins = (superman + starship) / god;

This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about.

Quote:

Avoid Documenting the "Obvious": If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come after you have no business modifying your code without thoroughly understanding every line of it.

Quote:

Long Lines: Try to pack as much as possible into a single line. This saves the overhead of temporary variables, and makes source files shorter by eliminating new line characters and white space. Tip: remove all white space around operators. Good programmers can often hit the 255 character line length limit imposed by some editors. The bonus of long lines is that programmers who cannot read 6 point type must scroll to view them.

Quote:

Use Three Dimensional Arrays: Lots of them. Move data between the arrays in convoluted ways, say, filling the columns in arrayB with the rows from arrayA. Doing it with an offset of 1, for no apparent reason, is a nice touch. Makes the maintenance programmer nervous.

And this one actually caused me to laugh out loud, prompting my wife to ask me what I was reading shortly before giving me that look that says "Oh, so it's one of those things you think are funny but that normal people find incredibly boring" and calling me a nerd:

Code:

class Truth 
  { 
  boolean isTrue ( boolean assertion ) 
    { 
    if ( assertion != false ) return assertion; 
    else return assertion; 
    } 
  } 

... 

Truth trutherizer = new Truth() ; 
if ( trutherizer.isTrue ( s.equals( t ) ) ) doIt = true; 
else doIt = false; 


// hint: all the above accomplishes is: 
doIt = s.equals( t );

07-09-2003, 04:46 AM	#2
Asha'man Veteran Member Join Date: Dec 2001 Location: southeast Posts: 2,526	Who said IF was bad? A couple of notes: There is a vast difference between compile-time efficiency and run-time efficiency. Adding a redundant paren has no effect on run-time performance, and a virtually unmeasurable effect at compile-time. On the other hand, an extra paren may save hours of developer-time. I don't see where the if statement is claimed to lead to spagetti code. Where exactly are you reading that?

Thread Tools	Search this Thread
Show Printable Version	Search this Thread: Advanced Search

07-09-2003, 08:16 AM	#7
NialScorva Veteran Member Join Date: Jan 2001 Location: Median strip of DC beltway Posts: 1,888	"Good programming practices" lists are almost always a list of results from good practices, not ways to achieve good practices. Removing gotos won't necessarily make your program any better, but a good program will contain fewer gotos. The single biggest problem with "how to program" guides is that they rarely understand this. Most of them are books that say "sometimes you need to sacrifice horsepower for emissions standards" and "Don't attach doors with wire, use hinges and weld them on", then claiming to be a book on building a car from the ground up.

07-09-2003, 08:58 AM	#8
Mageth Contributor Join Date: Jul 2001 Location: Deep in the heart of mother-lovin' Texas Posts: 29,689	PPS: That mistake does not have any negative impact on the accuracy of the program's results...as both my and [somebody's] runs demonstrated. I wonder if [somebody] could explain to us why? Blind luck?

07-09-2003, 09:19 AM	#9
Jesse Moderator - Science Discussions Join Date: Feb 2001 Location: Providence, RI, USA Posts: 9,908	Principia: Now for my rebuttal of DNAunion's strawman attack. DNAunion: Tsk tsk...going for the personal jabs already Principia? Can't beat me legitimately...so sad. "Strawman" is an attack on a person's argument, not on the person themselves, so it's not against the rules. But a number of Principia's other comments involved statements about DNAunion's motives, honesty, etc., and those are definitely not appropriate here. Principia, please either avoid these types of personal attacks in your posts, or don't post on this thread at all.

Freethought & Rationalism Archive

The archives are read only.