Is there A Method for Placing a Line Space after Each Function?

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.

I think regardless of the amount of sanitizing should be done, there is another point I would make in this situation...

23 hours ago, Josheir said:

One of the criticisms was the spacing seemed to be random in the functions.

Based on this, deleting all vertical white-space seems like using a rocket-launcher on a insect.

I would suggest looking at the code that prompted the critisism, and see how it could be improved. If possible, even asking for more detailed feedback might be an option ("what makes the spacing seem random?" "any suggestions for how spacing could be improved in this piece of code?", etc.).

The use of white space to make software code readable is vastly over rated.

18 minutes ago, Bregma said:

The use of white space to make software code readable is vastly over rated.

YeahitstotallysillyandIagreewholeheartedly.

[Slightly tongue in cheek, posted in good spirits]

If I'm using Visual Studio, I just go into the options and setup my desired code formatting styles once.

Then I open a file that has weird formatting and hit Ctrl-K Ctrl-D or Ctrl-E Ctrl-D, depending on which keymapping is in place on that particular machine. Boom, it's all formatted more or less consistently. That's almost always good enough.

If you have more than one person on a team though, you really want to enforce something consistent, or better yet, have your tooling enforce it automatically for you. It can be hell trying to merge code where two or more inconsistent styles have warred back and forth, or to understand the change diffs.

Just now, jpetrie said:

Going back and reformatting everything afterwards is not really a useful learning experience at all.

Well instead of not doing anything at all, changing the code even at the end of the project (which I'm not saying by any means is better than along the way,) is making mental connections with the actual code by: working on it, seeing it, doing it, remembering it. It is definitely better than nothing at all other than "next time." People tend to remember what they work on more than just wishing towards it with a future promise. Of course it is also important that we change are behaviors, but this is not yet an option in this case. What we're talking about is doing something valuable enough with our time over doing nothing and deciding that we will do the changes next time.

Over sanitized, well I don't think there is a penalty for making code better. If necessary, it could be explained.

Josheir

12 hours ago, Josheir said:

Well instead of not doing anything at all, changing the code even at the end of the project (which I'm not saying by any means is better than along the way,) is making mental connections with the actual code by: working on it, seeing it, doing it, remembering it. It is definitely better than nothing at all other than "next time."

But why do it at the end of the project? The whole point of code formatting is to make it easier to read and work on, which you wont be doing a whole lot of anymore. Reading over you code again to remember it is a good thing to do, but always signifies to me that if it's that complex to understand then it probably needs refactoring into smaller and more descriptive methods.

Whitespace isn't always evil either and people like the author of Clean Code recommend using it to break unrelated code up.

It sounds to me like OP wrote the code already but is interested in cleaning up existing work. It isn't a permanent arrangement, just the current situation. My interpretation is that he wants to continue using a cleaner style moving forward but has pre-written code that isn't conformant with the convention.

Every company I've ever worked with has had their own coding standards. They always include a caveat that if the code you're working on has other standards, do what nearby code does.

Every project I've ever worked on has had their own slight variations of the company's corporate standards. Invariably there is something specific in the project, for this reason or that reason the team can't abide by the organization's standards.

Every team I've ever worked on has had their own slight variations of the project's standards. Invariably there is something about a tool or a utility or a developer or a research paper, whatever the reasons, the project's standards and the organization's standards just don't quite apply.

If the compiler doesn't care, I don't care. Like everyone else, I'll try to make the code look consistent with the code around it.

But I'm not going to sit around all day adding a bunch of spaces so all the variable names make a nice vertical row, having all the parenthesis and commas in parameters lined up in neat vertical rows, or ensuring there are five lines of whitespace between each function. Every editor with even a modicum of code awareness will obliterate the formatting in an instant.

Do what works for you. It doesn't matter what the style is. It doesn't matter how many spaces or tabs you use, if you put spaces before or after parenthesis or commas, if you put braces on above, below, or on their own line. NOBODY CARES. Make it look consistent.

Since this is visual studio, that means opening the files, hitting Ctrl+K Ctrl+D. Clean out any extra newlines, and move on to things that actually matter. You've already mentioned using regular expressions for blank lines. Use that type of thing if you want, or just scroll through the files looking for violations that stand out.

If you're trying to spiffy things up for an interview, just like some people will iron their denim jeans so they look nice, if you want to do something fancy to your code in the hope it makes you look like a better candidate, do what you want. Just be aware that beyond simple consistency, nobody in the real world actually cares. Make it consistent within the files or within the system, then be done.