Two Spaces is great for Java, bad for Apex Code?

[brianmfear]

I believe there should be consistency with spacing, but it should always be one of the two methods mentioned here:

(a) Four spaces per indent, align function parameters and inline queries. This has the advantage of being able to use Developer Console's auto-format and auto-indent features, which is great for developers that primarily use DC and pull their code in automatically via Jenkins or other tools. I'd recommend this for any org that isn't suffering a character limit problem and wants to be able to use any and all tools available to get the job done.

(b) Tabs replace any series of four spaces, align function parameters and inline queries. This has the advantage of approximately 25% reduction of characters used in a typical code base. I actually removed 234,000 characters of code from a 1,000,000 character code base simply using Force.com IDE's Search Files function. However, I'd only recommend this if you have a tool that can automate this four-space/tab conversion, as the DC only uses spaces.

Asking for anything else is problematic unless you're going to say that using the Developer Console is 100% off limits, which doesn't work well for the org-per-developer design model, or, to a lesser extent, those that choose to use one IDE over another, Force.com IDE versus MavensMate, BrainEngine, etc.

[GradyD]

:+1:

[ckoppelman]

The goal of developing a standards document is to get everyone's code editor formatting into the same system, not to preference one IDE over another.

Honest question: Do people use the Developer console on such a frequent basis that it's important to keep in mind?

Stylistically, I have found that 4-character spacing leads to very wide lines of code. You lose 8 characters right off the batt to indentation for business logic. 12 or 16 for the entirely reasonable singly- or doubly-nested blocks of code).

If you cap your lines off at 80 characters, that leaves you with just past 50 characters per line of logic. Even that's okay until you realize that you're going to be using SObject dev names (Solution_Contact__c is 20 char).

That means a line like the following constructor cannot be nested inside two blocks without spilling over to a new line:

Solution_Contact__c solutionContact = new Solution_Contact__c();

I think it may be because I haven't been in SFDC-land very long, but the focus on fewer characters is quite strange to me. I happen to enjoy writing terse code, but for production code, I want to be clear. It seems like this is going back to the 1970s. Perhaps, @brianmfear, you can explain it to me?

[brianmfear]

Modern computers now sport 1280 or 1388 resolution screens (for low-end systems); even a simple $130 Chromebook can support 131 characters across in the Developer Console without using a smaller font. The most important part about the width is making sure that developers don't have to suffer the penalty of horizontal scrolling (ideally, every function should fit on a screen so it can be read at once, but this isn't always practical). Given this limit, four space tab stops is not as bad.

The problem with two space tab stops is that no IDE out there defaults this way, so every time you want to use a new system, you have to configure it, or do lots of back-spacing. Aside.IO, Force.com IDE, and Developer Console all use four spaces by default. Auto-indent uses spaces on all those systems, too (and probably others), so it's mostly about taking the path of least resistance, which is to simply leave the default alone.

I'd also argue that, with the higher resolution of today's screens, a tab stop of 2 might simply be too hard to read at a glance once you get five or six blocks deep, which shouldn't happen in theory (in most cases), but often does in practice because developers don't optimize their if blocks, put loops inside of loops, check for null unnecessarily, and so on. Of course, for any specific group, tab stops of 2 might be appropriate, but for a general audience (given average hardware and varying levels of technical expertise), I'd suggest leaving it at a tab stop of 4, maybe with a suggestion of using 2.

As far as the short, or literally descriptive abbreviated variable names... it's a trend. I'm not sure who's teaching it, or who's learning it, but it seems like the ecosystem is full of it. I personally try to avoid overly terse names, focusing instead on describing the contents of the variable. I might have to write my own little piece on describing variables. I know I've brought this up in other places, but I think it goes much beyond a general style guide and kind of wanders into the territory of just programming.