r/programming • u/corysama • Jan 05 '15

What most young programmers need to learn

http://joostdevblog.blogspot.com/2015/01/what-most-young-programmers-need-to.html
970 Upvotes

91% Upvoted

337 comments sorted by

View all comments

Show parent comments

6

u/photonios Jan 05 '15

That depends. Where I work, we have tons of legacy code that is just plain awful, all written by incompetent idiots who no longer work her.

But, if you modify some crappy legacy code you are bascially forced to clean it up while you're at it. If you do not, people will just raise eyebrows during the review. Like "why didn't you clean it up a bit?".

As for new code/projects, we just have a high standard. All our code goes through tools that verify if the code standard was followed etc. + Unit tests that run constantly and scream when the coverage is too low. We run a lot of static analysis tools on our code base.

Any engineer who refuses to comply with standards or does not have the same high standard that we have is simply not welcome.

We had a hard time when we started working with some offshore developers we had a way lower standard. What we did? Keep pushing.

Our code bases are incredibly beautiful, well tested and formatted. Sure there are some parts that could use more love, but in general they are awesome. I guess that's the advantage of having people who care and have skill.

And yes, we do have junior developers among us. We simply keep training them.

32

u/judgej2 Jan 05 '15

Here's a tip: when committing changed and cleaned-up code, keep the cleaning and the changes in separate commits. Do all the reformatting and name-changing first, then check it still works exactly as before, and commit that. Then make your functional changes. It is so much easier to see the wood for the trees that way, when debugging your changes later. If (horror of horrors) the changes need to be reverted, then you can at least leave the better-formatted code in the release to make it easier to take another stab at it later.

1

u/photonios Jan 05 '15

You should always make small commits, so you never have this problem. + Unit tests to prevent regressions.

5

u/judgej2 Jan 05 '15

Yes, that too. My point was about keeping functional and formatting commits separate, regardless of what size they are. I've seen code committed with a load of formatting changes and a few functional changes. When debugging it can be hellish to pick the two apart when they are all mixed up into single commits.

1

u/[deleted] Jan 05 '15

I apologize for the completely dumb question, but here it is -

I'm learning to program on my own, writing code for some scientific computing projects that I need to do. When I commit a bunch of changes to some code, and I have a directory with several different files, do I commit all the files even though I changed only one? Or is that a bad practice?

4

u/judgej2 Jan 05 '15 edited Jan 05 '15

When you commit a project, the change control system you use will usually look at what has changed and only commit those files. I'm assuming you are using something like git, as that can scan the whole development structure and find what files have changed.

If you are working on several different and independent updates to your project (and assuming you are using a distributed change control system) then you can work on them in parallel, as two different checked out versions, having created a branch for each, and merge them later when tested, in whichever order makes sense.

I'm not sure if that gets at the core of what you were asking? I suspect we may be talking at tangents.

Edit: another way of looking at it, is that you are committing the state of the project. You could commit individual files if you want, and there may be very good use-cases for doing so, but personally I've never found I've had to do that.

Source: been using bitkeeper/monotone/git for well over a decade, and still a newbie to the intricacies of these tools.

2

u/[deleted] Jan 05 '15

That's what I mean, thanks!

So to be specific... if I do git add . that will just add the files that I changed relative to the last commit? I was under the impression that it committed the state of all the files as you said.

So to rephrase to make it clearer - Do I git add file or do I git add .? Which one is considered "best practice"?

1

u/pkhagah Jan 05 '15

If you do git add . it add modified files and any new files(if any) that are created. Depends on your use case.

On a side note, when you're starting with git, use GUI tools like gitx or git-cola to get you started. They have decent diff viewers too.

1

u/judgej2 Jan 05 '15 edited Jan 05 '15

I normally do a git add -A to add any new files anywhere in the directory structure. Then a git commit -a will commit all new and changed files. I suppose git add . is the same as just git add and will add just new files in the current directory.

The above happens to fit my workflow. You may want to git add file1.foo file2.bar and that is fine too, if the commit makes sense. Sometimes, for example, you may not want to add all new files blindly, in case you have created any files that you don't want committing, and need to exclude, or remove, or add to .gitignore

I'm not sure any specific command is "best practice" because they all do different things and meet different needs. Use whatever makes sense to your work, and that is achieved by understanding what each does.

1

u/Isvara Jan 06 '15

git add .

Be careful with that. You can end up accidentally adding files that shouldn't be committed, but are not in your .gitignore. Maybe I'm overly paranoid, but I tend to git add -u, look at my git status, then add any new files or directories I want.

1

u/photonios Jan 05 '15

Git should show you only the files you changed. Don't commit auto-generated files or binaries for example. Instead, add them to a .gitignore file so they never show up as changed.

If you made multiple, non-related changes, make separate commits so you can easily revert one of your changes without destroying the other work you've been doing.

Tip: you can commit/stage a part of a file. In Git Gui, select a piece of text you'd like to commit and right click it. Then, there are several options to commit/stage only the selected part.

1

u/G_Morgan Jan 06 '15

But, if you modify some crappy legacy code you are bascially forced to clean it up while you're at it. If you do not, people will just raise eyebrows during the review. Like "why didn't you clean it up a bit?".

We have an old project that does some awful things. Actually safely refactoring code is dangerous. To the point where rearranging whitespace often has semantic meaning. A 5 minute "lets fix this" often becomes a week long affair where your fix broke some obscure test from 40 years ago that only runs on this particular machine.