I just removed all the white vertical white space for my C++ Visual Studio 2017 project using :   ^.$\n

What is the recommended standard for the spacing between functions.  Is it suggested that a line break be placed after each of the functions' closing brace?  If so, is there a convenient method or do I just go through all the code and press enter after each function?  Anything else I need to know about line spacing?

I don't mean to be petty, I'm just finishing up this project,

Thank you,

Josheir

3 minutes ago, Josheir said:

I just removed all the white vertical white space for my C++ Visual Studio 2017 project using :   ^.$\n

Why? Vertical space isn't something to be scared of -- it allows you to group or structure things within the current scope easily. This sounds like just a change without any solid reasoning behind it.

5 minutes ago, Josheir said:

What is the recommended standard for the spacing between functions.  Is it suggested that a line break be placed after each of the functions' closing brace?

Pick something and go with it.  Personally I like a line or two between each function, btu as long as it's consistent it doesn't really matter. Find something you find appealing and easy to read -- that's the most important bit.

7 minutes ago, Josheir said:

I don't mean to be petty, I'm just finishing up this project,

Why make sweeping formatting changes to the current project if all you need to do is finish it up? If you were unhappy with something, take that as something to change for the next project.

Also, I noticed that the .cpp files have one extra line space before the last brace when the function has no return (void return type.)  Once again, is this the standard and how is it changed to none?

Thank you very much.

Josheir

Well I'm polishing up this project so that it may be presentable if needs be (at an interview perhaps.)  One of the criticisms was the spacing seemed to be random in the functions.  I thought why not just make it all the same. 

Is it suggested that I do this all manually instead?

Thanks again,

Josheir

Making your formatting consistent is good. Just understand that everyone is going to do things differently, so it doesn't actually matter what you choose to do, so long as you are disciplined about doing it the same way throughout your code.

There is no such thing as a universal formatting standard for code.

If you want to format your code to be consistent, which is again a good thing, you should use a formatting tool like clang-format or Visual Studio's Format Document command (found under Edit menu -> Advanced). There's no need to do it by hand.

The main lesson in code style is that you find some set of rules that feels good to you, and learn to apply them while you enter or edit code. At some point you can do that automatically without thinking about it.

I've been using a Visual Studio extension called AStyle for C++ formatting. It allows you to set several options relating to braces, tabs, whitespace, etc. and it can be set to format on save.

I think changing the code if even a sweep is also practical learning.  This applies more to a different "sweeping change," being consistent with capitalization for different variable types and names. 

Josheir

Going back and reformatting everything afterwards is not really a useful learning experience at all. It's reinforcing poor behavior (the idea that you'll "clean it up later," which is often impractical in the real world), and not teaching you how to have the mental discipline to either 

(a) be consistent in your code hygiene practices as you develop or

(b) develop the tolerance for reading and navigating code that is not formatted in your current personal style of the month.

And it's mostly pointless, as others have noted: we have programs to do this for us, by choosing to manually reformat your code you're just wasting precious time.

Further, to your point about cleaning it up for eventual display in a portfolio... as employers who review code portfolios, we can usually tell that a piece of code has been overly sanitized. We want to see real code that is reflective of how you really work. Seeing that code in the state you will naturally write it is far more useful to us than seeing something you've taken and artificially cleaned up to fix every last minor style nit and document every last function extensively.

I would recommend you not do this in the future.

I actually disagree with the suggestion to not over-sanitize code. Reviewers will know that you put in extra effort, sure, but I don't see that as a bad thing.

What I typically would suggest is instead to over-sanitize the important parts of your code, and just format/lightly-comment the stuff that doesn't need as much explanation.

I would rather hire a programmer who submits thorough and clean code (and takes a bit longer to do so) than a programmer who submits messy but "realistic" code.