OCD with coding

[CrypticA1]

Hey who else here is a little OCD when they are coding. I hear that you kind of have to be when you're coding just to make everything legible. Sometimes i'll delete an entire project cause it looks wrong. Also I'm obsessed with my particular format and I have so many rules for organizing the basic structure. When I see code that doesn't look like mine I honestly struggle to read it. Anyone else get this way?

[Ganado]

The biggest thing that I would struggle with when reading others stuff is correct indentation. It should be immediately clear that I am currently in the scope of the while loop or if statement because the stuff will be indented past the condition statement.
Other than that, just consistent style overall is pleasing. Changing the style within the same function would get annoying, but one can't expect every file to have the exact same formatting unless the team is strict.
I don't agree with putting things such as "else while (...)" on the same line together, I've seen that a few times.
If a group of assignments or function calls are related, it might help to line up the equals signs/parenthesis themselves, to give the impression that these assignments all belong together.

Small things like

codeblock {
}

vs

codeblock
{
}

or tab vs spaces shouldn't matter. (But I do think 8 spaces = one indentation level is too long, I personally like 4. :> )

But no, I don't think I'd ever delete code (especially my own) due to bad formatting. It might make the difference on whether or not I use and understand someone else's though.

[JagerDesu]

I hate when people do this:

if(condition)
{
    DoThis();
}
else
{
    DontDoThat();
}

Instead of this:

if(condition)
    DoThis();
else
    DontDoThat();

If a condition can go without brackets, don't unnecessarily put brackets. The only exception to this rule in my style guidelines is when this happens:

if(condition)
{
    ThisWillTake();
    MultipleLines();
}
else
   DontDoThat();

This is when I would change it to:

if(condition)
{
    ThisWillTake();
    MultipleLines();
}
else
{
   DontDoThat();
}

When writing C, I really hate it when people typedef structs to avoid writing struct at the beginning. I want to know that it's a struct when I use a struct!

typedef struct
{
    int evil_level;
}this_is_evil;

this_is_evil evil_thing;

Should be:

struct this_is_heavenly
{
    int divine_level;
};

struct this_is_heavenly heavenly_thing;

[tition]

Here is what I have learned/read for source formatting:

- Consistency is more important than personal preference. If you join another person/company/team, you should use the same formatting style as your team, even if it means you need to make compromise.
- You can choose your favorite style only if you are ``the boss'' (or the first one to start the project, etc.).
- If possible, reach agreement on common formatting style with your teammates in person and, for a larger team, also via written guidelines.
- If you find it impossible to coordinate your team to a consistent code formatting, simply make everyone use automated source formatter (if you aren't the boss, suggest it to your boss). If you can't stand another's source formatter, simply write your own. This will also help you if you copy+paste source between differently formatted projects.

[TheIdeasMan]

JagerDesu wrote:

If a condition can go without brackets, don't unnecessarily put brackets

I disagree, I always put braces, even if there is 1 statement, and especially even if it is a null statement (which has a comment as well). This will save you one day when you add more code. I have seen plenty of examples of those who do exactly that, and wonder why things don't work :+)

My biggest bug bear is those who over-abbreviate their variable and function names.

I wish more people would format their parameter lists with 1 parameter per line, rather than them all on one line and overflowing into the next one. The compiler doesn't care about newlines in the code, it's really only interested in the semi-colon to denote the end of the statement. I much prefer formatting to make code readable, rather than some phobia about "Our code is the same, but yours takes up 80 LOC, versus mine which is only 50 LOC, so mine is better".

Am not a fan of really long std::cout statements either, people seem to forget they can build them up in stages, even if the output is 1 line. There is a kind of a rule about restricting code to 80 chars per line. In the old days, this was so one could print it on paper, but I dislike having to scroll 2 or 3 screens left and right in order to read the code.

Also not a fan of:

People Who((Run*everything)-together[like_this]);

I would prefer some spaces:

People WhoDont ( (Run * everything) - together[like_this] );

[RUNNER PRO AGARIO]

EXACTLY, One should Always put braces, even in one line statements, why? because suppose you want to change the block, you have to add braces there.


@TheIdeasMan couldn't really long std::cout statements be divided into multiple lines?


I also like including a constructor and destructor at the end of every class. I don't trust my compiler lol.

[Duthomhas]

I think formatting wars are stupid, pointless, wastes of bandwidth.

Braces or no braces is nonsense. It is only a minor issue with clueless newbies struggling to write their first two programs. Everyone else knows how to read an if statement, and if they screw it up they need to find a better job for ignoring obvious stuff.

I personally tend towards Whitesmiths style, but I often use Allman too. Does it matter? No.

Consistency and indentation that correlates with structure matter most when reading scope.

What matters more is clarity of algorithm. Use descriptive names and obvious operations. Let the compiler do its job.

Eh for now.

[RUNNER PRO AGARIO]

um....


░█▀▀ ░█▀█ ░█ ░█▀▀ ░░█▀▀ ░█▀█ ░█ ░█
░█▀▀ ░█▀▀ ░█ ░█ ░░░░█▀▀ ░█▀█ ░█ ░█
░▀▀▀ ░▀ ░░░▀ ░▀▀▀ ░░▀ ░░░▀░▀ ░▀ ░▀▀▀

[Moschops]

I think formatting wars are stupid, pointless, wastes of bandwidth.

Yet here you are contributing to one.

[RUNNER PRO AGARIO]

Wait, who said we were having 'a war'.


@Whoever reported my post


I DIDN'T MEAN TO OFFEND ANYONE

[Duthomhas]

Um, why is OP's post reported?

Moschops wrote:

Yet here you are contributing to one.

Um, preemptive strike?

RUNNER PRO AGARIO wrote:

Wait, who said we were having 'a war'.

I didn't. (I didn't think we were.)
I just said I think that they are a waste of time and bandwidth.

I also didn't say I would never contribute to said waste of time and bandwidth.

:o}

[Hirokachi]

@Runner Pro Agario & Duoas
I reported Runner's post because I thought it would not help anyone looking at the topic.

I guess I didn't think clearly enough about it.

It didn't occur to me that you were not trying to be rude or anything.

For that i am sorry.

I guess I just misinterpreted your "Epic Fail" remark as not helpful/not useful.

[cire]

There is a kind of a rule about restricting code to 80 chars per line. In the old days, this was so one could print it on paper, but I dislike having to scroll 2 or 3 screens left and right in order to read the code.

With widescreen monitors these days, is horizontal space really so hard to come by? ;)

[jlb]

Not everyone has one of those new fangled wide screen monitors.

Keeping the line size to reasonable lengths is still a good idea even with wide screen monitors. However the definition of reasonable lengths is subjective and shouldn't be written in stone, IMO

[TheIdeasMan]

RUNNER PRO AGARIO wrote:

@TheIdeasMan couldn't really long std::cout statements be divided into multiple lines?

Yes, that was precisely my point :+)

TheideasMan wrote:

....people seem to forget they can build them up in stages ....

One can have it on multiple lines, with a << at the start of each line.

@Duoas

Yes, you are right, but some of this stuff is useful for beginners IMO. I look at little things like this as defensive measures.

jlb wrote:

Keeping the line size to reasonable lengths is still a good idea even with wide screen monitors. However the definition of reasonable lengths is subjective and shouldn't be written in stone, IMO

Yes that's true, it is a subjective dimension.

It's just I am not of fan of having to scroll sideways. Sometimes the things that cause this are a massive std::cout with a comment on the end. Other things to consider: I know some people who still use the vi editor in a shell; not everyone has high resolution on their screen.

Having said that, I am looking at getting two wide screen high res monitors, to go with a wide screen laptop. :+)

[Ganado]

One can have it on multiple lines, with a << at the start of each line.

Real question is:

int a = b + c + d + 3432524 +
        3 + 3432 +
        42;

vs

int a = b + c + d + 3432524
        + 3 + 3432
        + 42;

I don't know which I prefer. The second one looks kinda cleaner. The plus sign (or whatever operator) is more prominent than a semi-colon, but the fact that it's "equals, plus, plus" shows the logical path clearly.

[cire]

Real question is:

As with ostream and operator << there is no real advantage to making these things one expression (as opposed to a long function call where its unavoidable.)

int a = b + c + d + 3432524;
a += 3 + 3432;
a += 42;

[booradley60]

Duoas wrote:

Braces or no braces is nonsense. It is only a minor issue with clueless newbies struggling to write their first two programs. Everyone else knows how to read an if statement, and if they screw it up they need to find a better job for ignoring obvious stuff.

Apple's goto fail comes to mind.

[Computergeek01]

Ambiguous variable names are my pet peeve. That, and macros that aren't all in caps. But at the same time, that's what find and replace is for so it's not actually a problem.

@ OP: You should NEVER delete your old projects. Data storage is cheaper now than it has ever been and we're talking about plain text files here. If you really can't stand the sight of them then bury them in an archive file; they compress rather nicely.

[RUNNER PRO AGARIO]

From variables and @Computergeek01's post about find and replace, I remebered this. I HATE programs in which people include 1 letter variables, exceptions (sometimes) being loops. Find And replace is a pain with them, which is why I never use 1 letter names, even like a,b, or c