Another post made me curious about this - if there are bad programmers, by definition, there must also be good ones. We'll say a good programmer is one that consistently writes good code, but that begs the question, what is good code?

It's an open question. Html code is very different from PL-SQL code. My theory is that mostly the same things make either type of code good or bad. I'm asking the crew what those things are. We have a whole range from people who are learning to people who are (unofficially) teaching in this forum, and I think we can all gain some knowledge if everybody contributes their thoughts on what makes a block of code good?

My two cents:

HTML

• Standards compliant and validates.
• Used for layout structure and uses CSS for design. (Tables are used only for displaying tabular data.)
• It's as simple as it can be and still accomplishes its function.

CSS

• Standards compliant and validates.
• No browser hacks. Uses conditional comments if browser-specific code is necessary.
• Optimized by multiple identical declarations on the same line and using shorthand.
• Logically organized.
• Images have been optimized and repeating images and sprites are used whenever possible.
• It's as simple as it can be and still accomplishes its function.
• It looks the same in all browsers.

JavaScript

• Degradable. JavaScript should be used to enhance, not provide, functionality. Anything it modifies should be able to work without it enabled. It should never be used as a sole means of input validation.
• Unobtrusive. Existing HTML markup should not be altered. The JavaScript should be completely separated.
• Does not throw errors on failure.
• Reusable and extensible. A class interface should be used in most cases.
• Does not directly control style. If style changes need to be made by JavaScript, have it change the CSS class, not the style itself.
• It's as simple as it can be and still accomplishes its function.
• It looks the same in all browsers.

XML

• Standards compliant and validates.
• Uses a namespace.
• Is appropriate for the situation? Some cases would be better served using a less bulky format like JSON.
• It's as simple as it can be and still accomplishes its function.

PHP

• Validates and sanitizes all user input.
• Does not recreate existing PHP functions (I say this because there are so many out there and some are rather obscure).
• Reusable. Has a class or function interface. Each class or function should be irreducibly complex and serve a single purpose.
• Catches errors and exceptions. Does not expose sensitive data in doing so.

SQL

• Normalized database design.
• Queries only get or update the information they need and no more.
• Calls to the database are minimized by using joins, etc where appropriate.

There is obviously a lot more than I wrote above, but I would also like to add to each of the categories above the fact that everything needs to be tested. This includes security testing, unit testing, user testing, and optimization testing.

My personal thought is that only acceptance and regression testing are truly necessary. Unit testing has value, because if your code isn't doing what you expect, there's no way the customer will be happy.

But my thought is that performance can either be defined by what's possible, or by the customer's requirements. It isn't always worth hours and hours of programming to optimize a routine that won't be called very often, or isn't terribly important. I've been pretty good (or bad?) about pushing this onto the customer. We can meet most perf requirements, but at a cost. If the "best practice" way to accomplish something meets the customer's wants, that's good enough. If a feature meets acceptance testing, it's fast enough, and if not, well, that's one reason it might not.

I agree with you on the performance testing. When I said 'optimization testing', what I was thinking was more along the lines of something that probably should be included in user testing rather than performance testing. Basically, can a user of your site or software quickly and easily navigate it to accomplish certain tasks? Is the interface 'optimized' so that common tasks are clearly and easily accessible? Another way to look at it might be optimizing a conversion rate where each conversion is a successfully completed task. This, though, may be something that can only be accomplished after extensive testing and over a period of time and I doubt that many people or businesses have the budget, time, or desire to do it.

And all of that, I suppose, doesn't really fit into the 'Is it good code' category. Perhaps the 'Is it good design' category, but that is a whole other topic.

Personally, I could care less if my front-end code validates, or if the JavaScript degrades gracefully in all situations (I sometimes write fat-clients, and will at least put a <noscript> tag up to tell people to turn it on).

I break a lot of rules on a daily basis. I even use hacks inline in my CSS files, because of how much it speeds up production. Despite all of the relatively nonstandard things I do during development, I still think my front-end code is good, because it is highly reusable, and I usually make good notes to make it workable by other people.

A very good point made in the last thread about code reusability matters a lot to me. This is not only important because other people can work on my code without asking tons of questions, but is also significant in the fact that the objects and functions I create now can be recycled by me on the next go-round.

I don't think good code means everyone should develop in the exact same way. We all have a unique way of looking at things, and no one knows everything.

Bad code is usually very poorly organized. It often relies on a hodgepodge of scripts that are thrown together from here, there, anywhere. I SOMETIMES WRITE BAD CODE, and when I do, it usually means I am in a hurry. The more experience I have, however, the more reusable code I've created, and the higher the quality of what I'm making gets. When stuff is reusable, production time gets faster, and I have more time to make good notes, which makes my work easier to read.

Like I said, I sometimes write bad code. However, I tend towards self-criticism, and compared to some of the stuff that is out there, I'm a **** genius. The problem is that there are just TONS of people that just jam websites together without much thought of how reusable and workable it is going to be in the future. They create without any thought of flexibility or growth, and don't really care, or else are ignorant. As long as it is rushed off the shelf, right?

Well, there is another related question of whether good code is practical code. I was just responding to what I thought good code is, but I don't think it's always practical due to time or budget constraints. For good practical code, I would say that my highest criteria are that it's functional, reasonably secure, and maintainable; probably in that order.

Originally Posted by VirtuosiMedia

Basically, can a user of your site or software quickly and easily navigate it to accomplish certain tasks?

This will sound nitpicky, but programmers need to be exact on the details. MySQL has no (graphical) user interface at all, and inherits the SQL language. Most users love MySQL enough to get heart tattoos with the dolphin on their arm.

Originally Posted by wayfarer07

I don't think good code means everyone should develop in the exact same way. We all have a unique way of looking at things, and no one knows everything.

I like this.

I think all good code, at least 99 % of it, has some things in common.

1. It's modular, which makes it reusable, and means it delegates work when possible, and follows a certain "meta" structure.
   1. For HTML, this means using CSS.
   2. For SQL, it means using stored procedures with input parameters.
   3. For procedureal code, it means using functions, instead of performing calculations inline.
2. A balance between perfection and performance, and between accomplishing the specific need. In OOP, there's a problem where scope creep can lead to the "God class" that does everything under the sun. And usually does nothing very well.
3. I'd write more, but need to run.