Tips for Developers

[CamiKaze]

what are you aligning? please lord above dont tell me you are one of those.

int variable1 =1;
int two =2;
int somelongername = 3;

public enum randomShit
{
variable1 =1,
two =2,
somelongername = 3
}

 

[Steamy Tom]

public enum randomShit
{
variable1 =1,
two =2,
somelongername = 3
}

christ why

 

[krycor]

what are you aligning? please lord above dont tell me you are one of those.

int variable1 =1;
int two =2;
int somelongername = 3;

Depends.. generally i only do it when it's already there and with large corp code repos i often see everyone has a variant of some arb indent/tab size which is inconsistently applied.. all of which should not matter if u stuck to the rule i.e. never align things with tabs.

That being said.. i hate devs that write & use weird arb abbreviations because it presents as a ivory tower nut case which makes me hate you a lot. simiarly for peope who don't write basic code docs and then use their own apis wrong.

Code that is functional & performant but looks like crap is crap.

 

[[)roi(]]

Depends.. generally i only do it when it's already there and with large corp code repos i often see everyone has a variant of some arb indent/tab size which is inconsistently applied.. all of which should not matter if u stuck to the rule i.e. never align things with tabs.

That being said.. i hate devs that write & use weird arb abbreviations because it presents as a ivory tower nut case which makes me hate you a lot. simiarly for peope who don't write basic code docs and then use their own apis wrong.

Code that is functional & performant but looks like crap is crap.

Do you use a rule based code formatter and linter? Fairly easy to maintain some level of consistency with that.

As for arbitrary abbreviations; I'm always very terse when it comes to building data types -- rather pointless dreaming up names for abstract constructs; whereas the code that employs those data types is declarative; because that's where it matters.

Anyway naming is hard; a common approach is usually part of style guidelines.

 

[krycor]

Do you use a rule based code formatter and linter? Fairly easy to maintain some level of consistency with that.

As for arbitrary abbreviations; I'm always very terse when it comes to building data types -- rather pointless dreaming up names for abstract constructs; whereas the code that employs those data types is declarative; because that's where it matters.

Anyway naming is hard; a common approach is usually part of style guidelines.

Not everyone uses an ide with white characters space showing.. I’ve yet to come past a code base where there is > 3-5 devs where 50% are not from the original team who have maintained the code base well.. always tabs and spaces mixed and used interchangeably.

It makes a difference because... non-coders look through code too and on a variety of devices too. What seems to happen is the developer things he can do an awesome thing, he understands it, codes it and if he goes.. ask that same developer 6-12m later about it and if they can’t understand why or what they’ve done for a few lines.. yip it was written badly.

Developing code is not purely about functional ability and performance .. it’s also about support & extensible ability both of which go down fast when the code bases can’t quickly be understood without heavy context.

Keep in mind what people do when confronted with this and under pressure to fix or make an addition.. yes, they don’t refactor, they add a new redundant code because the original is a black box which no-one knows about.

 

[CamiKaze]

Anyone interested in being a one man IT department?

 

[cguy]

Not everyone uses an ide with white characters space showing.. I’ve yet to come past a code base where there is > 3-5 devs where 50% are not from the original team who have maintained the code base well.. always tabs and spaces mixed and used interchangeably.

I expect that Droid’s point is that there are tools that will just fix the code files for you, that can be run prior to integration.

It makes a difference because... non-coders look through code too and on a variety of devices too. What seems to happen is the developer things he can do an awesome thing, he understands it, codes it and if he goes.. ask that same developer 6-12m later about it and if they can’t understand why or what they’ve done for a few lines.. yip it was written badly.

Keep in mind what people do when confronted with this and under pressure to fix or make an addition.. yes, they don’t refactor, they add a new redundant code because the original is a black box which no-one knows about.

The issue here isn’t just the developer, it’s the process. Neither of these scenarios should get past the review team, which eventually leads to neither of these problems existing anymore (developers know not to do it again).

 

[[)roi(]]

I expect that Droid’s point is that there are tools that will just fix the code files for you, that can be run prior to integration.

Exactly -- I was referring to tools separate from the IDE or editor.

E.g. If I receive code from someone else and prefer spaces instead of tabs; an indentation of 2 instead of 4, it's 1 liner in the terminal to adjust that.
Similarly a linter with a custom rule set can help to alleviate issues re company styling standards, etc.

 

[[)roi(]]

It makes a difference because... non-coders look through code too and on a variety of devices too. What seems to happen is the developer things he can do an awesome thing, he understands it, codes it and if he goes.. ask that same developer 6-12m later about it and if they can’t understand why or what they’ve done for a few lines.. yip it was written badly.

@cguy covered this -- should have been kicked out during review,

Developing code is not purely about functional ability and performance .. it’s also about support & extensible ability both of which go down fast when the code bases can’t quickly be understood without heavy context.

Sure, opinions on this is going to differ a lot based on the paradigm that you and / or a codebase employs -- e.g. if you follow clean code guidelines your functions would be very small and with SRP / totality they'd do only 1 thing and avoid surprises.

Personally my view on this has changed significantly over time and even more so since I switched from OOP to FP -- because today I find most OOP codebases unnecessarily complex to understand, maintain and test.

As for designing for extensibility my approach has again changed on this over time; I now tend to follow a principle like YAGNI with the belief that there's nothing easier to adapt than a composition of simple functions.

Keep in mind what people do when confronted with this and under pressure to fix or make an addition.. yes, they don’t refactor, they add a new redundant code because the original is a black box which no-one knows about.

A comprehensive set of tests will alleviate many negatives; the rest IMO depends a lot on paradigm, clean code, SRP, totality, ... + if it's complex and unavoidable then the documentation better be good.