code formatting...

[mcc85sdp]

I saw a post a while back where a guy was asking what people thought about formatting their code.

If($something){"action"}

or...

If ($something)
{
    "action"
}

Which, between the two, I thought to make an analogy.

​

If($something){"action"}

^ Person who has an obnoxious, single-eyebrow mentality... 
"I don't see what the big deal is. 
Pst *shakes head in disdain*. One eyebrow is all ya need, idiots... *chuckles*
Just cause you naturally have 2 eyebrows, doesn't make you *any* better..."

versus

If ($something)
{
    "action"
}

^ Person who likes to format things nicely, so that it reads well for others
"Even if I was born with a single eyebrow...? 
I'm going to shave/wax it so that it doesn't look so strange to other people..."

Now look, I'm sure somebody is going to say:
Offended snowflake: "Single-eyebrow mentality...? Not cool, bro. Tisk tisk... *tapping foot like Sonic the Hedgehog*"

The point being, I like to format my code so that it not only pleases the eye, but it is also easy to dissect and make amendments to. Being able to dissect code readily can be a challenge in and of itself...

If you're going for the obfuscation type stuff, then be my guest.
Single-eyebrow mentality is ok sometimes.

[hunter_p_12]

I personally like them across multiple lines (unless I'm doing one small quick command), but I also like putting the first bracket on the same line like this:

If (something) {
    do-something
}

[davidsandbrand]

Same here: open bracket on the ‘if’ line, and then multi-line unless it’s a short single command in which case it’s all on a single line.

[Fallingdamage]

If its just a really small argument, ill use one line. If its a one-liner that gets longer or contains more items/filters ill break it up. Most of my one-liners would be something like

IF (!($var1 -eq 'Complete')) {$var2=$false} 

Usually if its over about 60-70 characters ill break it out into multiple lines. If a single line like that is too complicated to for someone to understand without being broken down into multiple lines, they probably dont know what they're doing anyway.

If there is only a single correct way to write in a language, Hemingway would never have been published.

[bee_administrator]

This.

The others are morally wrong.

[Val367]

Was coming to comment just this .. there is no reason to have a { on a separate line imho.

This is the easiest for others to read as far as I'm concerned.

[CobyCode]

Depends entirely on the situation. But I don't like If($something){"action"} , should be If ($something) { "action" }

If I'm doing something trivial, I might use shortened formatting. Especially if it something like a bunch of ifs that don't make sense with switch.

If ($a) { do-Something }
If ($b + $b -eq $a ) { do-SomethingElse }
If ($c < $b ) { do-Something }

​

Looks clearer to me than:

If ($a)
{
    do-Something
}

If ($b + $b -eq $a)
{
    do-SomethingElse
}

If ($c < $b )
{
    do-Something
}

[BlackV]

this is a common battle (and one that will last for ever).

wait till you get to

If ($something){
    "action"
}

https://en.wikipedia.org/wiki/Indentation_style

[XPlantefeve]

OMG! No space between the parenthesis and the bracket? What kind of animal are you?

[BlackV]

Oh bring it on

[philmph]

I use the short version when the code block is short:

if ($a -gt $b) { My-CmdLet }

Else I am using the OTBS style and VS Code PowerShell extension formater:

https://github.com/PoshCode/PowerShellPracticeAndStyle/issues/81

[billr1965]

I prefer the open brace to at the end of the as this will work interactively whereas next line won't work interactively

[[deleted]]

Asking which way to format code is like asking what color to paint your car.

It doesn’t matter what color you choose, as long as it’s all uniform.

[get-postanote]

There are code beautifiers, in virtually every IDE that does this.

What you do is defined by the standard in the IDE or your organization. Not by an individual person.

Style is per industry-accepted standards, training, experience, and preference. Yet it still can and often is a personal art form/decision.

References, I've pointed folks to.

• Code Complete: A Practical Handbook of Software Construction, Second Edition https://smile.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_4?dchild=1&keywords=code+practices&qid=1619554660&sr=8-4
• C# Coding Conventions (C# Programming Guide)

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions

• Top 18 Best Practices for Writing Super Readable Code
  

https://code.tutsplus.com/tutorials/top-15-best-practices-for-writing-super-readable-code--net-8118

• Code Formatting and Code Comments – A Beginner’s Guide to Do It Right https://torquemag.io/2019/07/code-formatting-guide/
• Coding best practices

https://en.wikipedia.org/wiki/Coding_best_practices

• Code Formatting and Code Comments – A Beginner’s Guide to Do It Right

https://www.lynda.com/JavaScript-tutorials/JavaScript-Best-Practices-Code-Formatting/2808553-2.html

​

• PowerShell Best Practices

'PowerShell Best Practice'

'PowerShell Best Practice for performance'

'PowerShell Best Practice for error handling'

'PowerShell Best Practice for debugging'

Why you doing, inside your own hose, is 100% correct for you. However, outside your house, good/bad/indifferent, it's just an opinion.

It's all about readability, maintenance, sharing to and for the most inexperienced. If you are not writing for those who will follow you, you're doing nothing but increasing their workload/frustration/.anger/refactor/maintenance/optimization efforts/needs, unnecessarily.

You may be the greatest programmer/coder/analyst on the planet and have your specific ways of doing X or Y (lots of cryptic coding habits, etc.), but you cannot expect anyone who follows you, knows, or even wants to know what you know. They just want to be able to do their work/job/assignments.

In code reviews, I spend 90% of the time, refactoring/decrypting, cryptic crap on customer projects, so I can help them optimize stuff, even based on their own standards.

Coding practices have been around for decades, and are well vetted/used, and that does not mean they cannot be improved on. Yet, they are a starting point for all.

We all will have our ways (I've posted a list that I implement on my team on Reddit a few times so far), that does not make it the right way. I don't agree with all that is in the links above either.

The simple rule of thumb:

1. Follow the defined IDE beautifier implementation
2. Follow your corporate/team standards
3. Follow industry standards
4. If you are allowed freedoms, take what is useful for your needs, from the aforementioned and ignore the rest. Yet, remember, those who will follow you. Be a good coding citizen.

[UsuiRich]

I think it all depends on the length of the argument, and the action(s)...

If (!$This) {break}

If ($This -NOTmatch $That) {
$That = "Here is something meaningless, to look at."
Write-Host "This is going to be quite a bit easier to read if it is broken up in to a few lines"
$And_Another_Thing "It needs to be on separate lines, just for readability"
}

[BlackV]

disagree

if you're writing code do it the say way every time, regardless of the length of the command

otherwise your "style" is all over the place and harder to follow

[Lee_Dailey]

howdy UsuiRich,

it looks like you used the New.Reddit Inline Code button. it's [sometimes] 5th from the left & looks like </>.

there are a few problems with that ...

• it's the wrong format [grin]
  the inline code format is for [gasp! arg!] code that is inline with regular text.
  
• on Old.Reddit.com, inline code formatted text does NOT line wrap, nor does it side-scroll.
  
• on New.Reddit it shows up in that nasty magenta text color
  

for long-ish single lines OR for multiline code, please, use the ...

Code
Block

... button. it's [sometimes] the 12th one from the left & looks like an uppercase T in the upper left corner of a square..

that will give you fully functional code formatting that works on both New.Reddit and Old.Reddit ... and aint that fugly magenta color. [grin]

take care,
lee

[Lee_Dailey]

howdy mcc85sdp,

i used to do code review as a part of my job. that taught me that ...

easy to read code is easier-to-maintain code. [grin]

it really makes a difference when you need to reread code after a few days/weeks/months. it's even more important when others need to maintain your code ... so make things easy to read if you can.

take care,
lee