Linq2Horror
-
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.
-
(This is kind of off topic but:) I don't understand why they changed to defaulting to putting spaces at the front. If there are tabs (one tab per indent), it's easy for each developer to set his tab size to what's comfortable for him, and everyone gets to see the code with the indentation they like. As soon as it's spaces everyone's forced to view it the same way. I get around this by using a non-fixed-pitch IDE font (so spaces are narrow) but it just seems like a big step backwards. Tabs are there for exactly this purpose.
BobJanova wrote:
each developer to set his tab size
How? In Notepad or another text editor? In a terminus emulator? How about if I include a code snippet in a Word document? Or in a CP post? TABs are evil and must be abolished.
-
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.
-
BobJanova wrote:
each developer to set his tab size
How? In Notepad or another text editor? In a terminus emulator? How about if I include a code snippet in a Word document? Or in a CP post? TABs are evil and must be abolished.
-
Any decent text editor (including IDEs) will let you set the display size of tabs. So will Word. Most web browsers will display tabs in a <pre> as 4 spaces or thereabouts which is what most people use for indentation anyway.
BobJanova wrote:
Any decent text editor
I must not have any of those. Plus, the worse problem is files with mixed TABs and SPACEs. X|
-
BobJanova wrote:
Any decent text editor
I must not have any of those. Plus, the worse problem is files with mixed TABs and SPACEs. X|
Notepad++ is very good. Shows tabs, spaces, does column deletes and highlights matching brackets, braces, parens etc. Also has modes for different languages C#, C++, VB, Lisp etc. And it's free. :)
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis The only valid measurement of code quality: WTFs/minute.
-
I should probably clarify why and how this code was created: We have a relatively large codebase. Some code files are old (C# 1.0 times) and contain tabs instead of white spaces (this was the default setting in VS2003 if I remember correctly). Now everytime we edit one of those files Visual Studio (now 2010) starts replacing the tabs automatically. This is simply annoying when using diffs and can be a complete pain when doing merges in our SVN. So we just had the idea to replace all left tabs with one big update. While discussing on how to do it was just an amusing idea to make it with Linq. 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. Robert
Robert Rohde wrote:
Its nothing that will get checked in in production code or anything like that.
Famous last words there...
Let's face it, after Monday and Tuesday, even the calendar says WTF! Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow. You can't scare me, I have children.
-
(This is kind of off topic but:) I don't understand why they changed to defaulting to putting spaces at the front. If there are tabs (one tab per indent), it's easy for each developer to set his tab size to what's comfortable for him, and everyone gets to see the code with the indentation they like. As soon as it's spaces everyone's forced to view it the same way. I get around this by using a non-fixed-pitch IDE font (so spaces are narrow) but it just seems like a big step backwards. Tabs are there for exactly this purpose.
I agree most people don't use the View White Spaces option in edit and the readability of source code goes to hell when people are not maintaining a consistent spacing. There is also the benefit that using tabs also results in smaller files so there is less demand for storage for Source control history for files this way. In larger projects its noticeable.
nothing
-
Hi all, I think the following could also qualify as a coding horror but I intentionally wrote it this way (one giant linq statement) because of a discussion with a collegue:
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));
Here another version where I tried to get a proper formatting:
static void Main(string[] args)
{
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));
}So what does this do? . . . . . . . . . . . . . . . . . . . . . . . . args[0] should be a directory where C#-Files are located (*.cs). It opens all files, does a bit of
I love the smell of long and 'unreadable' LINQ queries in the morning! :D 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(); }
} -
Hi all, I think the following could also qualify as a coding horror but I intentionally wrote it this way (one giant linq statement) because of a discussion with a collegue:
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));
Here another version where I tried to get a proper formatting:
static void Main(string[] args)
{
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));
}So what does this do? . . . . . . . . . . . . . . . . . . . . . . . . args[0] should be a directory where C#-Files are located (*.cs). It opens all files, does a bit of
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."
-
I love the smell of long and 'unreadable' LINQ queries in the morning! :D 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.
-
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."
