Programming style abominations

The BBQ Pit
21

In respect to the two bracketing standards, all I’ve got to say–or rather to ask is which looks better:

This section is about Blah
Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat.

This section is about Ook
Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat.

This section is about Blah

Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat.

This section is about Ook

Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat. Once upon a time there was a goat.

Respectively, these are:


if (Blah) {
    upon_a_time(goat);
}
else if (Ook) {
    upon_a_time(goat);
}

and


if (Blah)
{
    upon_a_time(goat);
}
else if (Ook)
{
    upon_a_time(goat);
}

Personally, I prefer the former as it ties the condition in closer with the block when I’m reading through, but either works just fine.

22

Or, if not that a little indenting might at least make it less likely that the guy who sees it and modifies it will screw up.

E.g.,



if(cond)
    doWhatever();
else
    doTheOtherThing();

Well, who knows. The modifier may just add more indented statements to the else block without realizing he now needs braces, visual cue from indentation notwithstanding. Still, it’s something.

23

BTW, having said all of the above, how hard would it be to have a text editor or IDE that displays the code as you like it, but “under the hood”, the code is in the same format for all users, so that each user does not mess up the checking in and checking out of code?

For example, you tell your text editor that you like the ‘{’ on the same line as the ‘if’ statement, even though the entire group (and the CVS repository) puts it on the next line.

When you start typing a new ‘if’ statement, you enter the ‘{’ as you always do, but, behind the scenes, the text file being created actually puts it on the next line. You just see it as being on the same line.

When you read the if statements created by others, you see them the way you like them, even though, the underlying text file has them in different locations.

Anyway, this can be extended to a lot of things involving style. (For loops, indentation in general, int* x, etc)

Each user can have a c.style file, which the text editor or IDE can read and use that to present the data to you in the manner that you find most easy to read, while leaving the underlying text file intact. (I believe SlickEdit does have an option to specify the style you like, but it actually changes the text file, which screws things up in a shared project)

Is there anything out there like this? I don’t think this would be too difficult to create, and it would end all the holy wars about coding style.

24

Eclipse has the ability to re-format the code according to macro-defined rules (Ctrl+Shift+F) – but this actually effects the file on disk, not just the display on screen.

Don’t know about what you’re suggesting. I like the idea in general, although I’d add the caveat that the CVS (e.g.) commit process would have to send the file through a site-mandated reformatting macro of its own, in order to have some kind of consistent style present if the file ever has to be opened in a simple editor.

25

Another way to resolve this would be by having a c.style file in which you specify not only your own personal style, but the repository style as well.

The text editor would use the personal style to know how to present things to you, and would use the ‘repository style’ to know how to store things on disk.

Each user could have a different personal style, but all users on a project would have the same ‘repository style’, which, I guess would be mandated by the project admin/lead.

26

Uh…

I remember when my friend couldn’t get the little turtle to move.

That’s about all I can contribute.

27

Jeez, kids these days! Whining on and on… “oh, this evil programmer before me didn’t indent things the way I like it”. blah blah blah :rolleyes: You don’t know how good you have it! I remember back in the Dark Ages, when I was doing a programming internship. I was assigned to ‘clean up’ the COBOL payroll program, as it was ‘difficult to maintain in its current form’. I opened up the source file - holy friggin hell! Over 15,000 lines of code, all in a single procedure. Not a single PERFORM statement in the thing; over 250 GOTO statements. Imagine the worst possible way a person who obviously thought in ANSI 68 FORTRAN would write a COBOL program…and multiply by 10. Variable names were truly a work of art: WS-A, WS-B, WS-C, WS-D…well, you see where this is going. Yep, it’s going all the way to WS-Z, WS-AA, WS-BB… (For you kids, the ‘WS’ refers to WORKING-STORAGE.)

Somehow, I was able to get it into a structured format and fix a couple problems that nobody wanted to address earlier because of the coding style (style?). I got a real job at a real corporation. Got assigned to fix a problem causing abends in some program written in 360 Assembler. Here’s the source, here’s the most recent dump - fix it. Hey, this is the wrong source code: the machine code in the dump doesn’t match the source. Long story short: a bunch of MVI instructions which were used to move opcodes into place. The freakin’ program was modifying its own code on the fly. Everybody enjoyed the discussion that ensued when I went upstairs and found the original programmer and discussed his ‘coding efficiencies’ with him. (Granted, there was a time when such tricks were the only way out of a situation, but this was NOT true for this program.)

Bad indenting, indeed! :smack:

28

Bunch of youngsters. :frowning: :smack:

I remember when we had hexadecimal dumps and were glad to find the registers.

I remember when structured programming came in. ‘Perform’ instead of ‘Go to’. Designing the program first - hah!

29

10;“How frightened are you”
20INPUTX
30;“I programmed like this, way back when”
40FORY=1TOX
50;Y;“Fear me”
60NEXTY

30

The religious wars over braces make me glad I use Python. No braces or line terminators at all (well, except for a few colons, which I understand were included simply because it felt right). Since we all (should) use indentation, why not make it significant?



if bla:
  foo = bar1
else:
  foo = bar2

No other valid way to write it.

31

[ul]
[li]Fuck COBOL for staying COBOL: I can forgive some things (even the ALTER verb) because it was designed so long ago to fit on such small systems. But keeping the syntax while not giving programmers local variables is not excusable.[/li][li]Fuck FORTRAN for not dying: We can do better than FORTRAN. We have, in fact, multiple times. FORTRAN, the infantile disorder, still hangs on.[/li][li]Fuck Wirth: He knew the right way to go. He’d seen Algol 60 and Algol 68. Instead, he designed Pascal and then added to it without once materially improving it. His type systems suck, his syntax sucks, and his insistence on single-pass compilation as if it were a Holy Sacrament instead of a speed hack sucks the worst.[/li][li]Fuck C++ for being too large: I’m not talking about libraries. I’m talking about the core language: Conceptually, C++ doesn’t fit in anyone’s head. The C-like subset, the object system (a brutal loss in its own right), and the template system (another horrible loss) overload you because there is no common thread running through them. (Oddly, I have nothing against operator overloading. It just needs to be done tastefully, and tasteless programmers have plenty of other ways to screw you over.) Common Lisp, which is based on a few axiomatic special forms and some simple rules, shows how to be large without being overwhelming.[/li][li]Fuck Scheme for breaking car and cdr: I don’t care about the Lisp-1 v. Lisp-2 debate. I like Lisp-2s because I like to define my own names, but Lisp-1s are how non-Lispers think. However, there was no reason for Scheme to make car and cdr fail on the empty list. None. It is neither an aesthetic improvement nor a result of something else. Steele knew better. He had to: He implemented Scheme and predecessors in real Lisps.[/li][li]Fuck Java for ignoring Smalltalk: Smalltalk should have won. Failing that, Java should have stolen enough ideas from Smalltalk to become a pleasant, dynamic language well-suited to building GUIs within a bytecoded VM environment. Gosling could have fooled the C++ hacks with syntax. God knows C++ hacks aren’t afraid of syntax. Instead, it took another era to bring Ruby to the fore.[/li][li]Fuck Javascript for having no self esteem: It isn’t Java! It is nothing like Java! It is a good language! But you’d never know it the way it gets fucked around with by browsers and stupid, stupid hacks crapping out webpages that make the cursor grow a tail and butt-fuck Steve Reeves. It has a wonderful style of OO that solves the fragile base class problem, it dispenses with the stupider syntax, and it generally acts enough like Lisp to make it a wonderful prototyping language. First, though, you need to get it away from its abusive relationship with the Web and cure its identity crisis.[/li][li]Fuck C# for being completely unnecessary: In fact, fuck .Net and the CLR and everything Microsoft did when it found out Sun could stop it from perverting Java. My wrath especially focuses on C#, however, because it improves nothing and it adds nothing. It is just an off-brand Java for an off-brand garbage-collected runtime with an off-brand class library. I would have forgiven everything had C# been just a little bit better.[/li][/ul]

32

Here is one of my favorite transgressions:


try{
  // do lots of stuff
  ...
  // do complicated stuff
  ...
  // do more stuff
}catch (Exception e){
  e.printStackTrace();
}
// Move right along as if nothing ever happened

IMHO, swallowing exceptions is one of the unforgivable sins of programming. When that code gets into production, nobody will ever see the stack trace, and the program will possibly be in a corrupt state if an exception is thrown anywhere.

I’m glad Noone Special mentioned the single-line “if” statement. I have the distinct pleasure of writing our coding standards for our team and I specifically prohibit single-line “if” statements because of the risk associated with it.

In general, my concern is this:

You may be an excellent programmer with beautiful style, developing multiple smaller open source projects in your spare time when you aren’t actively contributing to the Linux kernel or rewriting delicate parts of MySQL.

However…

Everyone else I work with is on a team for a few months at best and has to fit in with the style chosen for the project. We need to be able to quickly add new team members and transfer knowledge about the project.
If everyone just does it one way (my way :)), then this process goes more smoothly.

We have a pretty printer in our build process that sledgehammers code into the preferred style anyway.

You’re all talking about indentation style; I am just trying to get people to indent.

ETA: I guess my “exceptions” example is less an example of style and more about a bug. It still bothers me!

33

A-f***ing-men!!!

Of course,


try
{
    //stuff
}
catch (Throwable t)
{
}

(I kid you not! :mad: :() takes the cake… :rolleyes:

Thank you, thank you, thank you! :slight_smile:

This was the main input I managed to get onto our coding standards.
Along with (and I paraphrase of course) “A Method SHOULD* fit on a single screen. If it doesn’t, consider breaking it up further!”

*SHOULD rather than MUST, so it’s a non-binding guideline. But at least it’s in there!

34

Our coding standards allow for



if (cond)
   {
   <statements>
   }
else 
   {
   <statements>
   }

I prefer that. I like seeing the brackets nested to the same level as the code they block off.

I’m all right with



if (cond)
{
   <statements>
}

But I, dislike



if (cond) {
   <statements>
}

I like seeing bracket pairs on the same line.

I see both points of view on



int* pX;

(pX is a pointer to int)

versus



int *pX;

(*pX is an int)

Know the second, because you’re going to one day see



int *pX, *pY;

so you want to make peace with that.

Regardless, those are pretty minor complaints in the OP.

35

I’ve taken over development of a mature (well, in the sense that it is unleashed on a user base, and used for actual business) set of applications. The code is an absolute fucking nightmare.

The thing is absolutely heaving with conditional processes that should have used Case statements, but instead are implemented as a long series of unrelated Ifs, interspersed with occasional If-Elses and nested Ifs - some of which alter the values of the variables being tested, changing the way they will be caught by subsequent statements in the list, for example (and this is a mild one) this bit of code that is trying to do some kind of rounding on a package weight:


if Weight > 1 then
   Weight := (Weight* 0.04) + Weight 
else
   if Weight > 1.3
    then
    Weight :=  Weight + 0.5 
    else
    Weight :=  Weight + 0.2;

if Weight > 2 then
   if Weight > int(Weight) then
      Weight := int(Weight) + 1;

The trouble is that on top of this being a difficult-to-comprehend mess, I have to actually work out what business rules the original programmer was actually trying to embody. It is a nightmare.

Also, there’s a lot of magic number stuff - as seen in the above code - if someone wants to change the point at which weights start to be rounded to the next integer, we have to recompile the program. Did I mention that it’s a nightmare?

36

I do agree with you, but don’t you think the Microsoft Foundation Classes (at least eventually) grew to a nearly unmanageable scope and breadth? I entered a contest back in the mid to late 90s, when 512 megs of RAM was a huge memory size. The contest was simple: state in fifty words or less what you would do with 512 megs of RAM. The winner would get the memory chips. I wrote, “If I had 512 megabytes of RAM, I’d write a Hello World program using the Microsoft Foundation Classes.” I won the chips.

37

Was it easier to just rewrite it from scratch? I’ve never even seen a GOTO statement in COBOL. I can’t comprehend variable names like that, either. Who names variables something so incomprehensible?

Oh, and Dark Ages? I was doing COBOL on the mainframe a year and a half ago.

38

I never programmed for any Microsoft API except MS-DOS. Besides, the language cannot be blamed for the libraries it is used to access (and vice-versa). For your own edification, though, here is a critique of the Windows API by someone who hasn’t been so lucky.

Good one. :slight_smile:

39

There was a time when memory and storage was such a precious resource that every possible tweak would be done to expurgate any and all unnecessary tokens. That meant things like two-digit years and brief abstract variable names.

40

:eek:

Thank you for that. After so many years of wondering whether I was just a bumbling idiot, I now feel vindicated:

The API is structured around a large and constantly evolving set of functions and is based on a problematic shared library implementation. The provided interfaces are complicated, non-orthogonal, abuse the type system, cause name-space pollution, and use inconsistent naming conventions. In addition, the functionality of the interface suffers from inconsistency, incompleteness, and inadequate documentation.A-fucking-men. (Bolding mine.)