[astrodust]

You know what "simple, readable code" is? It's something that hasn't been exposed to the real world.

Once your application has been in circulation, exposed to the elements, hostile or indifferent users, it will develop barnacle-like patches that look ugly but serve a specific and important purpose.

You can keep code clean(er) if you're vigilant, but sometimes there's no way to express very complicated logic in a concise manner. Often abstraction looks cleaner but generally only hides complexity and can tend to increase complexity on the whole.

[chernevik]

As a noob I find terms "simple, readable code" really confusing. I recently had to learn some PHP (I'm mostly Python) to implement a seemingly stupid simple interface between some HTML form input and a REST API. Should be simple, right?

But there is all this weirdness validating data inputs like dates. And we have to process the form data data so each field input goes to the proper API field. And hey look that mapping only varies in its _data_ among form / API target pairings, so I should abstract that code out into a function or I'll be chasing bugs through the copied-and-pasted. The API provides a library for formulating requests but this doesn't expose some key functionalities to unit testing so I ant to revise to do that. Et cetera.

And, the next thing I know this thing is umpty-ump lines, and while the scripts actually processing the data are reasonably legible, they're sitting over a tangle of stuff that's rather harder to navigate. I've got classes to manipulate various core data to produce various data structures supporting sundry activities, but this essentially means those data structures are abstractions and thus hard to inspect when trying to remember how some process is working or what's going wrong. (The unit tests are worthwhile if only b/c their check values provide concrete examples of how those derived structures look.) To make the code "simple" in one place, I've created complexity elsewhere.

Obviously, this is in part a novice problem. If I can lay out and document the supporting code better everything gets easier to follow. But still, 5000 lines to input some form data, am I doing this right?

So is "simple, readable code" that helpful as a goal? At the end of the day it seems like there is X degree of complexity in any of these tasks, and any strategy to "simplify" is really just a framework for deciding where to place what complexities. And if that's right, then "simple, readable code" can become either a time suck or a discouragement in a hurry. I'm either playing Whack-A-Mole as I chase Complexity from one corner to the next and back to the start, or I'm going home depressed b/c I'm too stupid to write "simple, readable code". It sounds great, I suppose it is where people end up when they get good, so it's probably very helpful as an indicator of whether you're good yet. But I'm not sure it's very helpful for figuring out how to get to good.

[kansface]

I'd suggest you read Code Complete. It clocks in around 1000 pages and you probably don't have to read every single corner, but it would be for the best.

Code Complete documents several best practices in coding based on internal reviews of large coding projects and publications. The point of the book is that your code will have fewer bugs and be easier to maintain.

Priorities for coding go something like this:

1. make it work

2. optimize for maintenance (ie, make it easy to read)

3. optimize for flexibility/speed (only if necessary!!!!)

You should not be chasing complexity from one corner to the next; complexity should nearly always be pushed down and sequestered where it can't infect other code. Simple, readable code is the primary goal. Perhaps it was Knuth? who said programmers should enjoy reading code on the weekend. I couldn't disagree more! Good code should have the opposite qualities of a good book. Every single step along the way should be perfectly obvious as if no other way existed; plot twists in code are bad! Elegance is good, while cleverness tends to be bad. Working on existing code is much harder than writing new code. What hope do you have with maintenance if you write something at the limits of your comprehension?

About 70-80% of the lifetime of any work on given code is actually in maintenance, not in writing it. Optimize for this. Documenting is not necessarily helpful, either. You should not document shit as being shit; instead, you should change the bad code!

Other things are mentioned too, like function length, number of arguments to functions, variable span length, and variable pass through. Really, give it a read.

[chernevik]

Code Complete is very helpful, read it several years ago when I was starting. The biggest take-aways were DRY and proper encapsulation / abstraction. I should probably go back to it, I currently struggle with figuring out where to put stuff but maybe the stuff that went over my head the first time would help with that.

thx

[rgoddard]

Well designed and well organized might be a better goal. As you suggest, there does is some bound on the minimum amount of complexity inherent in the problem. The goal is to reduce the unnecessary complexity in your code. Being able to recognize and remove unnecessary complexity is difficult.

[billpatrianakos]

You don't sound like a noob to me. It's important to just get some shit working sometimes. Clean ans readable is a nice goal to have. In fact there are a ton of things "good" coders do that we'd all like to strive for but in the end I always ask myself "is following x principle getting shit working?" and if the answer isn't a clear yes then it doesn't matter. We need to stop getting hung up on all this stuff. Just make something work. Try to be clean, concise, and readable but make sure the motherfucker works at the end of the day or it's a waste.