Discussion in 'Programming & Software Development' started by Luke212, May 25, 2010.
what is wrong with camelcase? I use it for local variables only.
the whole point is that if you dont see a return statement you will misunderstand the code. so where do you think it will be hardest to find a return statement? here is what i said originally:
if you put a few returns/throws/Asserts in the...
// validate inputs
block at the start, do you think that will get missed?
besides who gives a shit about a 5 line method anyway? any examples given here are academic. you cant refactor all your code unless you have unlimited money. so you are going to get big methods, and you are going to be tempted to put a return statement halfway down inside a deep block.
// validate inputs
Firstly, if you cared about clean code/clean design you won't have big methods. Fullstop.
Secondly, if you employ the boy scout rule, you will eventually refactor your codebase to a clean state.
If you're lazy, you'll just make excuses like "You need unlimited money blah blah blah" and well that's your prerogative. But don't encourage it.
I said it to you on msn, I said it again in the thread, and I'll say it again now. Read Uncle Bobs book on Clean Code. You will be thankful that you did.
Boy Scout Rule. What passive aggressive bullshit. You're just as likely to introduce a bug/regression making 'minor' changes to clean up the code.
that is a terrible rule!
either you do refactoring/cleaning OR you change code to fix bugs/ add features/ etc. if you do both at the same time you are bound to end up rooted!
That's what unit tests are for.
But I guess you don't do that...
There you go.
Now you can write your 500 line long methods. Write some unit tests. Then, oh wait...
There you go.
Now you can write your 500 line long methods. Write some unit tests. Then refactor those 500 line long methods into something that's readable, and ensure it still works as intended, by running those unit tests.
Edit: Forgot to add, since the code your currently writing is obviously legacy code and doesn't have unit tests:
oh sure because every line of code is uint tested correctly?
and even if it is, I stand by what I said.
change+refact module X, oh hang the unit tests stopped working.. now was it the refactoring that did it? or my change? obviously the change because the refactoring was nothing, so I'll go fix the unit test! :facepalm:
Well, I live in an age of great tooling and fantastic IDE's, but then again, I DO program on the .NET platform so I should come to expect that.
If however, like you described, you live in the early 90's of tooling then I can see how this might pose a problem... IF YOU'RE FUCKING RETARDED.
Seriously, is refactoring -THAT- scary for you? You should quit programming while you are MILES behind.
Learn2change,test,refactor. You know, Red, Green, Refactor? OMG! GROUNDBREAKING STUFF THAT IS!
I already went over this:
HAHAHAHAHAHAHAHA good luck with that. by all means PLEASE stay in your little .net bubble.. and leave the big scary world of unmanged code to the big boys
Glad to see you guys are a mature bunch.
How bout we lose the name calling and insults and stick to the facts.
Alternatively, I can close this now.
Code coverage tools can help point out deficiencies.
Almost there, but you're thinking in too big a chunks. You should be running testing very often so you wouldn't get to the point where you couldn't work out if it was the change of functionality or the refactor that followed that broke the tests.
So now you know what parts of the system have been effected by what you've done. It gives you (and whoever else works on the system now or in the future) the confidence to make changes. Yes, you'd need to change tests, but that saves you from manually checking every time you change after the fact.