There are ''at least'' 5 types of BadCode:

	1. Code that does not do what it is intended to do.
	1. Code that does not perform as fast as it could.
	1. Code that is not easily understandable.
	1. Code that does not PickTheRightToolForTheJob.

Where is it specified what the code is intended to do?

	1. Code with explicitly IntentionRevealingNames. This requires a high level of abstraction to be useful.
	1. In UnitTest''''''s.
	1. In AcceptanceTest''''''s.
	1. In my head. This is '''not''' a GoodThing.
	1. In a functional specification. This is not a GoodThing either, if there are no corresponding UnitTest''''''s or AcceptanceTest''''''s.

----

BadCodeCanBeWrittenInAnyLanguage because we code in our heads, not in our machines - ProgrammingIsInTheMind. Therefore, bad code is caused by bad thinking, and we can think badly regardless of our tools or the means of expression. No language can actually guide the programmer's thinking to the point that only good code can be produced. At best, such a language would lose most of its generality.  More likely, restricting the language to eliminate bad code is probably equivalent to (or perhaps even more difficult than) proving a program's correctness. Perhaps it is even equivalent to solving the HaltingProblem. I don't know. I certainly do not expect any such capability to ever be available.

-- RobWilliams

''Perhaps "lose most of its generality" is not such a bad thing. There are many LittleLanguage''''''s / DomainSpecificLanguage''''''s that don't have much generality, yet are seen as quite useful (in their niche).''

----

To take the analogy one step further, it would be like restricting a human, written/spoken language in order to improve text and speeches? Right, bad text can be produced in any language. On the other hand, every human language ''is'' somewhat restricted by its grammar and vocabulary. -- FalkBruegmann

----

Is it true that G''''''oodCodeCanBeWrittenInAnyLanguage?  I think not, InterCal and BrainfuckLanguage being two examples of languages that make it difficult to write code that satisfies any accepted "good" quality.  But good code can be written in commonly disdained languages like Visual Basic and Fortran, so maybe it is safe to say that G''''''oodCodeCanBeWrittenInAnyGoodLanguage.

Ideally, we always choose the best programming language for the job. But sometimes, we have to use a non-optimal language, or use a language we don't know well. In those situations, we can always fall back on the tried-and-true programming techniques of DoTheSimplestThingThatCouldPossiblyWork, choosing MeaningfulName''''''s, writing MeaningfulComment''''''s, and decomposing the solution into a set of small subroutines/functions/definitions/rules.

-- KrisJohnson

----

BadCodeCanBeWrittenInAnyLanguage, thus, it is unfair to judge a language by its worst practitioners.

''In my experience, "BadCodeCanBeWrittenInAnyLanguage" isn't normally used as a response to judging a language by its worst practitioners; it is used to dismiss criticism of a language without having to consider whether that criticism is justified on technical grounds. -- DavidSarahHopwood''

It is useless to try to eliminate bad coding by eliminating features of the language. I've seen coding style requirements that rule out most of the useful constructions in the language, and I've seen companies ''invent'' languages while deliberately leaving out features, because some programmer didn't understand those features and proceeded to misuse them and write some horrible, unreadable code. Limiting the language is a bad solution to a legitimate problem. In fact, it leads to ''more'' unreadable code, since complexities of the problem are forced out of the language and into the programs written in that language. (The good solution is to educate the wayward programmer or fire him.)

For example, take Java's decision to eliminate overloaded operators. Why did they do that? "Well, we'd seen lots of pathological C++ code where people did things like '''int a; stack s; s+= a;''' to push onto a stack, and so we wanted to eliminate the possibility of that." Also eliminating perfectly good code like '''vector3d m; quaternion q; m = q * m * q.inverse();''', but that didn't bother them. And that's why JohnCarmack isn't writing Doom III in Java.

''That's ridiculous.  Are you Carmack?  If not, then perhaps you shouldn't be claiming he doesn't use Java because of something silly like operator overloading.  Does he even use C++?  He certainly used to use C (no idea if this is still the case), which also doesn't support operator overloading.''

I interpret this not as "because of something silly like operator overloading", but rather that the point about operator overloading is evidence that Java arbitrarily prevents him from using useful things.  Certianly the inverse square root trick often (mistakenly?) attributed to him isn't going to work in Java.

----

The best language for the job philosophy is discussed in greater depth on HorsesForCourses. But sometimes a problem decomposes into several subproblems, and a different language is "best" for ''each'' subproblem, and maybe you can't use CORBA (see e.g. MetaProgramming and LanguageORientedProgramming).

''AlternateHardAndSoftLayers perhaps?'' MultiLanguageRefactoring? SymbioticLanguages?

HelloPolyGlots? ''I like this suggestion.  Bad code can be written in multiple languages '''at the same time!''' ''

------

Some languages '''encourage''' a bad programmer to make bigger messes. For example, in Pascal you are hard-pressed to make a customized IF-statement or loop block, but in languages such as LISP it is a snap. Some languages will herd you toward a certain style (for good or bad). It thus makes it easier to read such programs because you know they won't deviate too much from that style and you are (presumed) used to that style if you are familiar with the language. 

----
CategoryCodingIssues