Developer Styles

[cesbrandt]

 @James ‌ and I kinda went of on a tangent, hijacking the Calendar Event Manager document thread (sorry about that  @chadscott ‌), 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:

Processes

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.

Styles

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.

Needs Improvement

Everything!

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?

[James]

Awesome discussion topic, cesbrandt.

I'm not quite sure what adaptation consideration is, so I'll talk about the coding style in this message. If I find time, I may come back to talk about how I throw a program together.

My code style is heavily influenced by other programming languages that I knew before learning JavaScript. Even though I know the scope of a variable is within the block and everything is hoisted to the top, I still tend to put the var statement when I first encounter something rather than at the top.

I use Eclipse (Windows) for development although I sometimes use a text editor PSPad (Windows) or Joe's Own Editor -- joe (Linux because it reminded me of Wordstar -- I don't like vi) or even the built-in script editor in Firefox. Tampermonkey has one, but I rarely develop in Chrome to start with.  Of those, I use Eclipse to do the formatting. Configure it with my preferences, press Ctrl-F and let it do it's thing. The Firefox editor has a "Pretty Print" that comes out close, so I'll use it in a pinch. I've tried online code formatters, but wasn't impressed as much and wanted something built into the code editor.

I use code lint/hint features. Not always, but I use Perl Critic for Perl that tries to make my code conform to Perl Best Practices by Conway. I was glad to find JSHint for JavaScript. There is an Eclipse plugin for both of those and so Eclipse helps me find / fix bad code by putting a little marker and explanation next to each trouble spot. My early code doesn't reflect it, but after I found it, I make sure that all of my projects are clean of issues.

I indent using 2 spaces. When I first started developing with Eclipse, I was writing PHP Drupal modules and they had Drupal Coding Standards, which was based off the PEAR coding standards. So I tried to make my PHP code match their guidelines. Also, the width of a tab is not defined consistently. Most "dumb" browsers define it as 8 characters, but coding editors allow you to adjust that based on the file extension / programming language. I hated opening up a file that used tabs but didn't have a recognized extension and only being able to see a small portion of the code because it was pushed off the right with those 8 character tabs.

When I started learning JavaScript, I started with Google's JavaScript Style Guide. They also recommend 2 spaces and not tabs.

I set line length to 120 characters. Sometimes 128 because I really don't care, I just want it to be more than 80. If you set it to 80 and have long lines, then the formatter sometimes breaks them in undesirable places. When it breaks, then JSHint starts complaining about the line break being in the wrong spot.

I don't want the line to be too long because then you have to scroll too far to read it and you've lost the left side of the screen when you do that.

When posting code in the Community, I sometimes manually add extra line breaks to minimize the scrolling. When you get a comment to a comment to a comment and then start posting code, there's little space left. But normally I let the code formatter take care of it.

What's a comment? Ever hear of self-documenting code? If there is something really unusual about what I'm doing or if I want to make a note to myself about why I'm doing something a particular way (something that's not obvious) I may add a comment.

I do tend to use generic variables i, j, k for my indices in a for loop. That allows it to be reused without having to change all the variable names. I picked up the i, j, k from my days as a founding member of SAFAC (Students Against Fortran And Cobol). I never had either, but I helped others with both and i - n were implicitly declared to be integers in Fortran. Plus, in math, we use i, j, and k as the indices on summations, so it meshes well with my primary job.