Eschew obfuscation -- again
-
While tip-toeing through the tulips of LLVM, I came across a section of C++ code that follows: //===--------------------------------------------------------------------===// // Instruction creation methods: Compare Instructions //===--------------------------------------------------------------------===// Value *CreateICmpEQ(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_EQ, LHS, RHS, Name); } Value *CreateICmpNE(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_NE, LHS, RHS, Name); } Value *CreateICmpUGT(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_UGT, LHS, RHS, Name); } .... And there are about 20 or so similar functions. My point is not about the code, but rather the "layering" of one-line functions. Relatively recently, someone made a comment in another about function size (I apologize--I don't remember the thread) and it reminded me of days gone by when we had a recommended function size of 40-60 lines of code. The reason for the function size at that time was so that a complete function would fit on ONE printed page (maybe two pages for a really complex function). Paper size was commonly 66 lines x 132 columns. The idea was that each function would be printed on a separate page and you would be able to look at a page to see the complete processing of the function. Looking at the above code, where a uniquely named function is created for each parameter type adds unnecessary complexity to the code. Further, these functions, along with many other more complex functions, are in a C++ header file. IMO, this is the type of coding practice that I personally do not like because it adds a layer of unnecessary complexity. Just my thoughts....
I agree with you completely, but then people also tell me my functions are too long. :laugh:
Real programmers use butterflies
-
I agree with you completely, but then people also tell me my functions are too long. :laugh:
Real programmers use butterflies
-
Written before compilers didn't inline one-liners unless in a .h? Converted from some macro shite? An optimization for when the operator is known? Widely agreed to be swill but a culture of not deprecating and deleting?
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I think the "page size" was more to do with getting people to think "modular" than to do with printing.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
While tip-toeing through the tulips of LLVM, I came across a section of C++ code that follows: //===--------------------------------------------------------------------===// // Instruction creation methods: Compare Instructions //===--------------------------------------------------------------------===// Value *CreateICmpEQ(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_EQ, LHS, RHS, Name); } Value *CreateICmpNE(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_NE, LHS, RHS, Name); } Value *CreateICmpUGT(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_UGT, LHS, RHS, Name); } .... And there are about 20 or so similar functions. My point is not about the code, but rather the "layering" of one-line functions. Relatively recently, someone made a comment in another about function size (I apologize--I don't remember the thread) and it reminded me of days gone by when we had a recommended function size of 40-60 lines of code. The reason for the function size at that time was so that a complete function would fit on ONE printed page (maybe two pages for a really complex function). Paper size was commonly 66 lines x 132 columns. The idea was that each function would be printed on a separate page and you would be able to look at a page to see the complete processing of the function. Looking at the above code, where a uniquely named function is created for each parameter type adds unnecessary complexity to the code. Further, these functions, along with many other more complex functions, are in a C++ header file. IMO, this is the type of coding practice that I personally do not like because it adds a layer of unnecessary complexity. Just my thoughts....
-
Probably because most people view code on screens that in IDE's that have maybe 12-20 lines visible. My own preference is to see the whole function without having to scroll up/down.
The screen I do my coding on is a 22" portrait monitor so I can get at least vertical 66 lines at once; I also have about 100 characters width which is enough for most purposes. I despair when I see colleagues using big wide monitors in landscape mode with just 20 lines of code tucked at the left side in the first 25% of the screen and a huge swath of blank space over most of the screen. :-(
- I would love to change the world, but they won’t give me the source code.
-
While tip-toeing through the tulips of LLVM, I came across a section of C++ code that follows: //===--------------------------------------------------------------------===// // Instruction creation methods: Compare Instructions //===--------------------------------------------------------------------===// Value *CreateICmpEQ(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_EQ, LHS, RHS, Name); } Value *CreateICmpNE(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_NE, LHS, RHS, Name); } Value *CreateICmpUGT(Value *LHS, Value *RHS, const Twine &Name = "") { return CreateICmp(ICmpInst::ICMP_UGT, LHS, RHS, Name); } .... And there are about 20 or so similar functions. My point is not about the code, but rather the "layering" of one-line functions. Relatively recently, someone made a comment in another about function size (I apologize--I don't remember the thread) and it reminded me of days gone by when we had a recommended function size of 40-60 lines of code. The reason for the function size at that time was so that a complete function would fit on ONE printed page (maybe two pages for a really complex function). Paper size was commonly 66 lines x 132 columns. The idea was that each function would be printed on a separate page and you would be able to look at a page to see the complete processing of the function. Looking at the above code, where a uniquely named function is created for each parameter type adds unnecessary complexity to the code. Further, these functions, along with many other more complex functions, are in a C++ header file. IMO, this is the type of coding practice that I personally do not like because it adds a layer of unnecessary complexity. Just my thoughts....
I think you should try to look at a bit bigger picture. This code by itself is rather ugly BUT it is likely to greatly simplify things downstream from it so it can work in a more uniform manner. I have had to resort to layers of ugliness like this on occasion and I only did it because the pay-off later was worth it.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
I think you should try to look at a bit bigger picture. This code by itself is rather ugly BUT it is likely to greatly simplify things downstream from it so it can work in a more uniform manner. I have had to resort to layers of ugliness like this on occasion and I only did it because the pay-off later was worth it.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
My preference is to look at a piece of code and understand the what's, why's, and how's very, very quickly. Looking at the above LLVM code (and I see this coding style in a lot of other code nowadays) makes it very difficult to understand what is going on. Why did the author of this code feel it was necessary to write 4 lines of a function call that simply added one parameter based on the function name to another function call? I can imagine situations where something like this might be appropriate for reliability, efficiency, clarity, etc. but in this case, these functions are called two times in the complete LLVM package. Maybe it would be appropriate if there where thousands of calls, but I don't see the need here.
-
My preference is to look at a piece of code and understand the what's, why's, and how's very, very quickly. Looking at the above LLVM code (and I see this coding style in a lot of other code nowadays) makes it very difficult to understand what is going on. Why did the author of this code feel it was necessary to write 4 lines of a function call that simply added one parameter based on the function name to another function call? I can imagine situations where something like this might be appropriate for reliability, efficiency, clarity, etc. but in this case, these functions are called two times in the complete LLVM package. Maybe it would be appropriate if there where thousands of calls, but I don't see the need here.
Why? That's what I was trying to guess at in my post above.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Why? That's what I was trying to guess at in my post above.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.The "why" is understanding why the author did something a particular way or in a particular sequence. Example: A lookup table might be searched sequentially, hashed, keyed, b-tree'd, linked list, etc. It would make little sense to use a b-tree or hash algorithm on a table that never exceeds 10 items. Likewise, it might make sense to use a hash algorithm on a sparsely populated table. I once wrote a an algorithm that used the first alphabetic character as an index into a 26 element table of linked lists where each major link list entry had sub-linked lists (almost a b-tree with sub-entries). This table of approximately 15,000 entries was accessed 1,000's of times per second and was dynamically updated with entries to be inserted and deleted. The processing sequence had to be very clear and understandable.
