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.