|
Robert Rohde wrote:
Directory.EnumerateFiles(args[0], "*.cs", SearchOption.AllDirectories).AsParallel().Select(f => new { File = f, Bytes = File.ReadAllBytes(f) }).Select(f => new { File = f.File, Bytes = f.Bytes, Encoding = f.Bytes.Take(3).SequenceEqual(new byte[] { 239, 187, 191 }) ? Encoding.UTF8 : Encoding.Default }).ForAll(f => File.WriteAllText(f.File, f.Encoding.GetString(f.Bytes).Split(new string[] { Environment.NewLine }, StringSplitOptions.None).Select(l => new { Line = l, Index = l.Select((c, i) => new { Char = c, Index = i }).FirstOrDefault(c => c.Char != ' ' && c.Char != '\t') }).Select(l => l.Index == null ? l.Line : l.Line.Select((c, i) => (i < l.Index.Index && c == '\t') ? " " : c.ToString()).Aggregate((s1, s2) => s1 + s2)).Aggregate((s1, s2) => s1 + Environment.NewLine + s2), f.Encoding));
did you honestly check in code like that ? if so WHY!?!
|
|
|
|
|
From my other post[^]:
Quote: The code was executed exactly one time (ignoring test runs) and will never be touched again. Its nothing that will get checked in in production code or anything like that.
|
|
|
|
|
but why ever have it in that "minified" unreadable format?
|
|
|
|
|
I love the smell of long and 'unreadable' LINQ queries in the morning! 
Actually I think the well formatted isn't THAT hard to read. I guess it depends on what you're used to.
Basically, a quick look at the (formatted) code tells me you enumerate through files, do this parallel, select some stuff, use this to make another selection, with this last selection you loop through all items in that collection and ok... It gets a bit fuzzy after that, but you end up selecting individual lines and even chars and putting them back together again.
That's probably more than I could tell from a quick look at any piece of 'normal' code.
The horror in such code lies not in readability (not using LINQ might stretch the code to twice or thrice its size and many 'normal' code is just as unreadable), the horror is in debugging these things! You can't make changes while running, you can't see the values of variables, you can't see the results of functions... It's a disaster!
That said, I wouldn't use it in production code, but as you mentioned, neither do you 
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
AHhhhhh, finally someone who feels with me and doesn't take it too serious.
Thanks
|
|
|
|
|
Interesting, I actually prefer tabs.
I hope you're aware that this will totally stuff up all your source control. I'd branch the existing to maintain history and then you may as well throw away the old trunk and start again.
"You get that on the big jobs."
|
|
|
|
|
RobCroll wrote: Interesting, I actually prefer tabs.
I would say 2 developers have at least 3 opinions on that topic
The screw up isn't that bad. At least not worse than before. Prior to our change the code gradually changed from tabs to spaces. Now we have one final commit which changes it all at once (about 1/3 of our codebase is affected). When viewing history, making diffs or merges we know the exact revision to exlude.
|
|
|
|
|
Ok I get it. Better to totally stuff it up once and then exclude that revision than watch it slowly get worse and worse.
I remember the first time I bumped into this. Started work at a new place, committed some changes and about 10 minutes later, someone comes up and asks me to change options to tabs. 10 minutes!... damn code Nazis.
"You get that on the big jobs."
|
|
|
|
|
Didn't notice this little piece of code and it was making me think some sections worked completely different than they actually do.
if(m_Config.m_isContinuous && false){ }
else{
}
Guess that was left like that for lack of time to clean up or something... but it shure led me astray... 
modified 24-Jan-12 11:04am.
|
|
|
|
|
Faked left and went right.
|
|
|
|
|
That's sort of a way to (temporarily) comment-out the then-section for testing. It probably shouldn't have made it to production.
|
|
|
|
|
Like Ryan said above... it totally faked me out...
|
|
|
|
|
Yeah, I've been known to do this at times, but I'd hope I'd never manage to check one in to source control!
|
|
|
|
|
PIEBALDconsult wrote:
That's sort of a way to (temporarily) comment-out
the then-section for testing. It probably shouldn't have made it to
production.
It might actually be intended to stay in there until the developer's sure that the previous condition won't ever be used again...or the logic within the condition, which may be useful in a modified condition but might be difficult to remember. Sometimes it's easier to do that when you think your boss/customer/vendor has lost their mind than to trust that you'll remember exactly out of which source version you chopped it if you need it back NOW.
|
|
|
|
|
Yeah, things like that have a nasty habit of sneaking in to check-ins then making it to production code. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
My (latest) compiler has a "dead code" checker.
We currently have
"Dead code (e.g. 'if (false)')"
set as a Warning, but I would like to promote this to an Error.
I like to say that the Compiler is a programmer's best friend, just make sure you don't put blinders on it or it can't help you.
Personal Pet Peeve: initializing variables to 0 or null when you can safely initialize a few lines later.
|
|
|
|
|
englebart wrote: Personal Pet Peeve: initializing variables to 0 or null when you can safely initialize a few lines later.
I'm sure somebody else' pet peeve is... "wait to initialize variable when you could've just done it with the declaration". Most C programmers do it that way...
|
|
|
|
|
While porting an old DOS software to Windows that controls a temperature bath, i came across this code to show error messages:
COUNT showerr(COUNT res)
{
char *szGp;
...
sprintf(szGp,"ibsta:%x iberr:%x ibcnt:%x",ibsta,iberr,ibcnt);
...
}
There are 18 lines of code between declaration and first usage.
The date of last modification was in 1997. The oldest sources I found are dated 1996, but I know that the initial sources must be from about 1989 (they should exist somewhere on floppy disks and printed sources may be buried somewhere in the basement storage).
The colleagues from the calibration lab told me, that they always wonder why the software often locks after showing an error message.
|
|
|
|
|
That's pretty darn ironic... an error in the showerr() function... 
|
|
|
|
|
Albert Holguin wrote:
That's pretty darn ironic... an error in the
showerr() function...
yeah, ironic...believe me, if you've ever had to diagnose one, you feel, hmmm, pressed 
|
|
|
|
|
So, "software", with over 20 year old code,
AND STILL IN USE?!
lol
*points and laughs loudly*
I wonder who will be scratching his head trying to understand my codes in 20 years... He's probably not even born yet. Ahhh, he will have a good laugh too, reading my comments in the code, and then posting snipplets here... lol
|
|
|
|
|
Last I heard, code I started maintaining in 1988 was still being used in a COM object behind a benefits enrollment system (it was ported from another program to deal with Federal Income Tax). Software archaeology is not an oxymoron.
|
|
|
|
|
Jochen Arndt wrote: controls a temperature bath
After reading this and then showerr I wondered why the function wasn't named bath, and noted there is a typo in the function name (the double 'r' at the end).
Then I realized the posting was about something entirely different...
Jochen Arndt wrote: they always wonder why the software often locks
Woot, they wondered for decades and never demanded a fix?  Can I have your users please?? 
|
|
|
|
|
Stefan_Lang wrote: Woot, they wondered for decades and never demanded a fix? Can I have your users please?
It is a controlling app that does not require user interaction after optional initial settings upon starting it. Reported errors are serious and the app is waiting for any key press and terminates. So they decided that it does not matter.
The users are not as pleasant as you think. They complain about many things. But with most questions they ask me, I ask them: Did you tried F1?
|
|
|
|
|
Stefan_Lang wrote: Woot, they wondered for decades and never demanded a fix? Can I have your users
please??
Can't fix it unless you can find it, and an uninitialized pointer can often be found to be pointing at something that looks like valid memory (say, some other string's buffer that isn't getting used at the moment) so the error doesn't occur all the time. Errors like this become "cold cases" because there are so few clues to follow. I sort of doubt that the users were quiet about it, either.
Pertinent to but opposing a point made by someone's tag line I read today, this is why I always initialize as close to the definition as possible, just to keep in the habit - I work in environments that assume initialization as well as environments like C where assumptions make asses out of everyone.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
