Sad part is that when you see code from professionals you realize that a lot of pros use a lot of bad code.

Forgot about catching up with tdwtf for a while:

private static bool InvertBool(bool org)
{
  bool returnValue = false;
  if (org)
  {
    returnValue = false;
  }
  if (!org)
  {
    returnValue = true;
  }

  return returnValue;            
}

Oh my.

Lots of programmers don't understand booleans, return values, function parameters, etc. I saw lots of things like this as a GA:

bool rv;
int i;
i = 42;
rv = some_function(i);
return rv;

The reason is they would always think that when you call a function that takes a parameter named i, that you would also have to send it a parameter named i. And directly returning the value of one function call just blew their minds.

I usually create my classes one function at a time.

Seeing a ! should be as natural as seeing + in code. It's not about overly brief, it's about NOT replacing an already implemented operator with no good reason. I understand ignorance on some functions of the standard(for example, I really didn't know there was sscanf for reading values from strings nearly a year ago), but the author of the snippet clearly knew the operator existed... he even used it in the definition.

James is probably referring more to things like:

return (b = func1(a + func2(func3() * magic_number) / func4())) ? b : func5(b);

That ends up looking like this.

Being clever, in the real world, is only great when you want to flex your programming fu and don't have to worry about ever revisiting the code.

My boss runs in circles all day because be produces undocumented, intricately designed code that is never meant to be changed or looked at. I produce well-documented code that is designed with practicality in mind. When the inevitable change requests start rolling in, I finish my mods before anyone else.

Work smarter, not harder. Everything in moderation. Etc.

It's perfectly fine to make mistakes, as long as you learn from them. Doing the same retarded thing over and over is the mark of a PHB.

It makes things easier to read. I have one class for printing, one for calculating the same thing 50 million times, and one for stupid shit that gets repeated over and over again.

I guess you've never broken down your code to make it easier to read.

Two reasons:

• Just because you get paid to do something doesn't mean you're good at it; some shops hire based on actual skills, but there are plenty of places where you can get pretty far with a combination of a college degree, meaningless fact memorization, and personal marketing skills.

• As a professional, there are always real-world constraints on your programming: you are on a budget (which means you can't sink infinite amounts of time into a task), you are on a deadline, there's an existing codebase you have to work with, the specifications are unclear, contradictory, or outright impossible, there's other team members with incompatible ideas, etc. etc. Sometimes, the proper solution would require a month of feature-freeze, and the customer cannot afford that, so you start out with a hack and try to gradually phase toward the proper solution. Sometimes, you are looking at a ten-thousand-LOC file full of puss, and you have to implement a small change; you can't rewrite all the puss in the time you have, so you read enough of the mess to make sense of it, clean up what you reasonably can, and do what it takes. Since you have to at least partially go with what's there, the code you add isn't going to be pretty, but it will work, and it will be a bit better than what was there.

Functional Programming is more than cleverness and elegance for its own sake; there are actual practical benefits, such as simplified static analysis and formal proof-of-correctness, simplified unit testing, easier parallelization and distribution of execution, etc. etc; however, OOP and enterprise programming get along very well, and it's hard for any other paradigm to break into this marriage. The reasons are many, but I guess the most important ones would be

• Similar structures. OOP with its class hierarchies and locally-imperative approach is very similar to how a typical business is structured, and the way functionality is encapsulated and bundled through several layers looks a lot like the way management layers distribute and delegate tasks. Because of these similarities, OOP programmers and designers have an easier time communicating with non-technical managers; given an intelligent non-technical management type, I could easily explain an OOP design in terms they can understand, but I'd have a much harder time doing it with an FP design - simply because there isn't anything in the organisation of a business that resembles partial function application, closures, monads, or any other core FP concept.

• Tradition. The business world has used imperative and structured programming since the early days of COBOL, and OOP, which inherits most of this heritage, is a logical extension - after all, a class is just a subprogram with its own local state, and a method is just a procedure with a scope.

• Available programmer material. The way things are at the moment, OOP programmers are plenty, but FP programmers are scarce. Finding a few dozen code monkeys to hack on your Java codebase is easy (though you get what you pay for), doing the same for a Clojure application is much harder. Try outsourcing a PHP project, then try outsourcing a comparable project written in CL. Try C# vs. F#. Of course, if it's excellence you're looking for, then the paradigms are probably almost on par, and programmers in that category will be more likely to be comfortable with either, and most of them will have developed a hybrid style that takes advantage of many different paradigms.

• Tools. Let's face it: OOP has the better tools. When I do OOP, say, in C++ or PHP, I miss an interactive environment like Common Lisp's REPL, Haskell's ghci, or Python's interactive interpreter, but other than that, there are more and better tools to choose from, and almost any tool you could use for a functional language is also available for OOP, either because it's language-agnostic, or because someone has written an equivalent. Of course, the fact that functional languages tend to come with less boilerplate and better language features to reduce cruft somewhat alleviates this (a lot if you ask me), but it remains that the comfort of a modern IDE is at least significantly reduces for FP languages.

• Trust. The above points combined also lead to a higher level of trust among business users for OOP. Given the choice, they rather trust a programming paradigm that has shiny tools, is used throughout the industry, and can be explained in layman's terms without leading to utter confusion, than one that seems to require a PhD to fully understand, has only text-based tools that look like random gibberish, is used mainly in academia (thus, by PhD's), and even confuses experienced programmers. And I can't really blame anyone, even though FP may actually often be the better solution, bottom line.

Currently working on a pure terminal address book app. Right now I have a few things missing that I hadn't figured into the original paper design (yes I actually set down and laid it out on paper to an extent, which I never do). I normally just tell myself, "I want to make <app/game>.", open IDE and terminal and start writing code without thinking it out. This time that isn't the case. It's an abandon project I decided to pick up from scratch and try actually thinking it out before I started coding.

Parts of the code is test code til I get everything addressed (no pun intended). Been bouncing back and forth between the book files, menu files, and main file.

Do to size I put the code in a spoiler to not fill so much of the screen.

#ifndef ADDRMENUS_H
#define ADDRMENUS_H

#include "addrBook.h"

void menuSystem(addrBook& Book);
void addMenu(addrBook& Book);
void editMenu(addrBook& Book);
void deleteMenu(addrBook& Book);
void viewMenu(const addrBook& Book);

#endif

Ok, thanks for that. My CS book I'm using as reference doesn't say anything about that, just to use reference on get functions with multiple parameters or return values needed.