[gravypod]

I've often wanted to talk to people about things like these and I'm often pushed back by people saying "This is simple, we all know this" but I don' think that's the case. If anything I think we know very little about how to keep software clean and simple. I've been trying to change that in my works by having people comment on my code that I've recently written for homework but people aren't really up for the idea.

I've had one discussion that stood out. We were talking about functional programming and I said that the idea of functional programming was the segregate state to the smallest unit of computation that must operate on it. I was met with my "friend" just blindly telling me to "stop saying that". I asked for a counter argument to that statement but they just said that I should stop saying that.

We as a community are horrible at speaking about code quality , evaluating each others work, and even just sifting out opinions from facts. It's crazy and it's something that needs to change if we want to take our field to a future where we can all be happy with the code we are writing.

I've got some suggestions I'm happy to talk to others about. My email is in my about page on this website. Please comment here or email me and I'd like to talk about this!

[hyperdeficit]

This is a real problem in our industry. We all like to think that we 'know' how to write good code, after all we read 'Clean Code' once. That, combined with either overconfidence in our abilities or the negative perception that comes with not knowing the answer to every problem leads to a lot of software that has applied 'good' coding practices and architecture to produce a mess of awful code.

In reality it is probably a lot more like learning how to apply any other concept, it takes practice, yet we don't spend enough time practicing our craft. This is particularly a problem because in the course of developing a product you will only get to implement a new solution to a problem a few times at best, or once more likely. This means we don't get enough experience with the different possible approaches to really internalize what a 'good' solution looks like.

We spend much more time learning the software development approach du jour, XP, Scrum, Kanban, Lean, etc. It doesn't matter what software development approach you use if the output is an unmaintainable mess of code.

[gravypod]

Honestly the best way to go about this, in my mind, is to make criticism ok in our industry. I've been trying my hardest to get someone I know to comment on my implementation of a CS280 homework I've been working on. I want to get to the point where I can properly write this code so it is readable to everyone. It seems like every time I ask someone to do this I'm told "Why would you want me to tell you how to code"

That's insane! I think that a goal of any programming course around the world should instill the idea that getting your peers to modify and read your code is a must in our industry. People need to be able to com along, see what you've done, and understand it.

If anyone want's to comment on my code that I'm talking about in this example it can be found here:

Implementation: https://git.gravypod.com/gravypod/school/tree/master/cs280/h...

Assignment: https://web.njit.edu/~gwryan/CS280/CS280-Program-1-Fall-2016...

I've attempted to live up to what I think is "good code" but no one want's to tell me if I'm right or wrong or even discuss this for fear of hurting my feelings I presume. I always get "run valgrind or a linter on it" and I've done that and come up with no ways for improvement. Everything is all opinion and no fact in this business of code cleanliness although this should be a cornerstone topic for the software development industry.

[l0b0]

Have you tried codereview.stackexchange.com? I find it can be a nice way to learn what others prefer and get tips for improving clarity especially in languages that I'm new to.

[ThrustVectoring]

That's a hard thing to get. A lot of people will play shitty status games and make feedback to try to prove they're more clever than you. And since people do that, genuine feedback can often get interpreted that way.

[chiefalchemist]

That's a good point. There's bad code. And then there's that's not how I would do it code. Too often, in public the latter gets treated like the former. When you're still open to learning this is confusing. That is, do I suck? Or is that feedback coming from an asshole?

[collyw]

The thing that taught me the most was writing an application and having to maintain it for 4 years. You see where the pain points are (as you end up revisiting them often), and you have no one to blame but yourself. You learn from your own mistakes.

I also learn from other mistakes as well. I has a habit of inlining conditionals in python -

   if False : continue 

until I noticed that the same style made reading someone elses code harder. I didn't notice it in my own code as I was more familiar with it. When I did notice I stopped doing that.

Keeping the logic as close to the data as possible helps as well (ideally in the data schema if possible). I think Linus's quote about bad programmers worry about the code, good programmers worry about the data and their relationships is true for most of not all levels of the stack.

[pikzel]

It's -presented- in a very simple way. The list doesn't give any real insight or even a single code example. That's why they say it's too simple, and you say we know very little about it, and you're both right.

[gravypod]

The problem is we don't have much in the ways of examples.

I'd say one of the few people in the world who has given grade-a examples is Rob Pike. That said I don't agree with him on much but I do very much respect his talent for simplicity. I'm directly referring to his Regex parser. It's amazing work although I'd much rather see him implement it live from scratch.

Something like the SICP lectures on youtube. It's amazing what they go over and do in that class and how they teach you about abstracting your problem domain.

[witty_username]

My email is [e-mail]

You can discuss it with me.