James Jones and I kinda went of on a tangent, hijacking the Calendar Event Manager document thread (sorry about that Chad Scott), discussing this. Now, everyone knows James, having published so much for the community that I'm not even going to pretend to take up a fraction of his shadow, so we all are familiar with his coding style and how it has evolved.
Of course, outside perspectives on styles and reasoning are muddy, at best. We don't know what another coder was thinking when they wrote it (I hardly know what I am thinking when I am writing something, the code just appears sometimes). However, I have found that understanding the reasoning behind doing somethings influences my reasoning and my style of coding adjusts accordingly. Other times, it simply gives my insight into why others doing things a certain way, even if I ultimately decide it's not a change I would want to make to my own methods.
So, I thought it might be welcome idea to open the forum to discussion of the styles, processes, and reasoning of various developers. Also, if you're feeling brave, share some things you believe you can improve on.
Important Note: Before I jump into this, I know how the Internet can be, even with a good community like this. Please remember that this discussion is not for judging each other. I believe the learning and developing processes never end and want to learn from everyone else. So, if you choose to participate, don't be afraid to offer suggestions to someone, but please provide reasoning for them, too.
Here's a little about my own:
I don't think, I just do!
Yeah, that about sums it up. I know how to plan out a project, design it, then write it, but I ultimately find it is a waste of time considering that nearly everything I do is solo development. As a team project, yeah, it's VERY important that everyone know what is planned and how it's designed. This allows them write their portions to fit with those of everyone else. It's a great way to do it, even for solo development, but I develop too much too quickly to spend that kind of time planning. As such, I plan as my fingers fly.
I actually consider myself to be more of an old-school developer, but I've been forcing myself to adapt to the new times.
My preferred style of development is very...strict, for lack of a better term. I write my code to be precise format, from indentation to positioning of brackets and spacing between functions and their supplied variables. The appearance standards of my code has changed very little over the years (I used to despise using tabs for indentation, but I've gotten use to it in recent years), but the code has.
I am a very procedural person, and my code reflects that, but I am also adaptive. In recent years, and more so since starting to work with Canvas, my code has "loosened up" and become much more modular. I've even started to learn to work with libraries and frameworks, rather than shun them as a crutch and just one more thing to have to learn.
More seriously, there are two aspects brought up during my discussion with James that I'm rather embarrassed by my lack of progress with: comments/documentation and adaptation consideration.
As James pointed out, I do try to add some sort of commenting to the code I post. I try to, at least, identify what each function does from a grand scheme perspective. However, that's actually something I do as part of my adaptation consideration. The code I use and publish that no one else will normally have access to see is commentless (except for the occasional "add/update this for that" comment). This is reflective of my personal belief that if you are unable to understand the code, you shouldn't be messing with it. I'm guilty of it and do my best to learn what the code does before I try messing with it.
Regarding the adaptation consideration, that's mostly regarding my modifying code fragments that I make public. Since I already addressed the comment bit on this, I won't rehash it, but it's also referring my code. As I mentioned above, I have strict rules that govern the appearance of my code that I following without remorse (I'm sure a few people have noticed that when I've tried to help with their code, what I post is formatted differently). In many cases, this is not the friendliest for other people. A common rule I've heard is to keep lines no longer than 80/120/160/200 characters (tabs equally 2/4/8 characters). I just need to be more mindful that when I release fragments publicly, it should be easy for anyone to step in and follow the code (something that fights my belief about being able to understand the code at every corner).
So, what do you like/dislike about my styles/processes? What would you suggest for my improving them? How to you code?