Thread: onion stlye of coding

  1. #1
    Banned
    Join Date
    Nov 2007
    Posts
    678

    Unhappy onion style of coding

    Code:
    int add(int a, int b) { return a+b; }
    int addThem(int a, int b) { return add(a,b); }
    int addition(int a, int b) { return addThem(a,b); }
    // ... 
    int main()
    {
        return addition(-5, 5);
    }

    i am sick of this onion style of coding
    can someone please give me a little comment on this, possibly giving reasons, why it can be useful?
    Last edited by manav; 04-17-2008 at 06:40 AM.

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Well, obviously your simplified example is very silly, and if the compiler doesn't optimize it, the above code is a complete waste of CPU time (and in this example, makes the code harder to read, which is not to anyones benefit).

    But there are reasons why you want to encapsulate and isolate different portions of code in various portions of source file. Most often you see this sort of thing in C++ rather than C, where things are going from one class to another, without actually doing anything with the data passed around - just passing it along to the next level in.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by matsp View Post
    Well, obviously your simplified example is very silly, and if the compiler doesn't optimize it, the above code is a complete waste of CPU time (and in this example, makes the code harder to read, which is not to anyones benefit).
    thanks Mats! yeah i know the example seems silly, but i have literally the same situation, where a function in one class, calls other function in other class, which calls another function in another class ... and so on!
    my gut feeling says, that, this is natural in case of object oriented programming.

    but i am unable to justify. why and how it is better?

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    It's better in sense that code won't be duplicated and depending on how well the functions are designed, it could potentially increase encapsulation.
    Plus it makes it more readable instead of writing "x, y, z" you call a function saying "dothis", so you know exactly what it does.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Well, it is a case of isolation - you call the next level class to solve the problem, and do not need to know what it does in your class. But it can be silly at times. If the functions are available to the compiler to inline, then the cost in CPU performance will be low, but it still gets hard to understand the code.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,788
    Each class has his functions

    For example I could have
    1. object that reads/write to/from socket
    2. wrapper for the object above - that concatenates/splits messages that are too long
    3. Actual message processor - that generates the message string based on the data to be sent
    4. Some object that contains the data

    So my 4 level object has a small string to be sent - it passes this string to the layer 3 object to construct a message
    That object does nothing - just passes it to layer 2 Splitter
    Splitter does nothing - just passes the string to Socket Writer

    seems to be a litte overworked, but in the scenario, when data are long and not in the string format - each object provides its own processing of the data... So if the result is broken - looking on the type of the corruption we could figure out which obiect is responsible for it...

    Also In the schema it is easy to replace socket with some other transport - because we only replace one small object and not the 10000 lines long monster
    etc
    All problems in computer science can be solved by another level of indirection,
    except for the problem of too many layers of indirection.
    – David J. Wheeler

  7. #7
    Banned
    Join Date
    Nov 2007
    Posts
    678
    a side note:
    i noticed that i misspelled "style", so i edited it, now it shows corrected in my post, but out side it's not changed!

  8. #8
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    That type of code usually shows up on heavily maintained code with few established rules. The next generation of maintainers feels there ought to be a better name for some function and encapsulate the original one, thus not breaking the old code and allowing themselves to use their own naming style/convention/whatever.

    It's debatable if it has any advantages. Formally, a function that does nothing but encapsulate another function is a waste of resources and should be avoided. However, it's sometimes important when new strict naming conventions, for instance, are in place and old code must not be broken. It's also usually done in conjunction with namespaces (in the C++ world).

    If however there is no reason for it, then it's bad practice across board. Bad practice because it makes the code harder to maintain (imagine having to add/delete an argument of the original function); Bad practice because it uses system resources; Bad practice because more than one function does the exact same thing, when we must strive to keep a 1:1 ratio between functions and functionality.
    Last edited by Mario F.; 04-17-2008 at 07:57 AM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #9
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    I had sml this semester and these types of things were more useful when you have heavy recursive programs and didn't want to clog up the main recursion with local functions or anonymous functions.

  10. #10
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    Quote Originally Posted by manav View Post
    thanks Mats! yeah i know the example seems silly, but i have literally the same situation, where a function in one class, calls other function in other class, which calls another function in another class ... and so on!
    my gut feeling says, that, this is natural in case of object oriented programming.

    but i am unable to justify. why and how it is better?

    It's not always better, it can be a sign of feature envy which would suggest a flaw in the underlying design of your class structure.

    In general though, having functionality in modular components makes it easier to reuse and maintain.

  11. #11
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Whining about styles is a stupid thing to do.

    For example this style...
    Code:
    int bla(int blabla)
    {
        //bla
    }
    ...annoys me a bit but that doesn't mean I should whine.

    People like different styles, there's nothing you can do about it. Onion style is perfectly OK for me.

    Now make sure the next topic you make won't be named "Why do people like olives?".
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  12. #12
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by maxorator View Post
    "Why do people like olives?".
    Cuz they are so damned tasty of course Nothing beats a nice bowl of steamed Brussel sprouts with a garnish of diced garlic, green and black olives saute'd in butter.

  13. #13
    Registered User guesst's Avatar
    Join Date
    Feb 2008
    Location
    Lehi, UT
    Posts
    179
    I see how that would be onion style, but when I saw it I was thinking about when you use a function's return value as the call for another function, like:

    pook(foo(bar(), 5, tool()),6);

    I've seen it. I've done it.
    Type-ins are back! Visit Cymon's Games at http://www.cymonsgames.com for a new game every week!

  14. #14
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by abachler View Post
    Cuz they are so damned tasty of course Nothing beats a nice bowl of steamed Brussel sprouts with a garnish of diced garlic, green and black olives saute'd in butter.
    Yeah, I like olives too.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  15. #15
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Meh, well, that's just how you write the function call.

    quz( bar( foo(), 42 ), 24 ); is just the "use it or lose it" idea of calling a function for its' return value. You could also "store it or ignore it" which might make things more legible for some.

    I interpret "onion style" as delegating work, which is always useful in my experience. For example, using some methods internally for similar types of work is helpful, rather than resorting to something perhaps tedious or difficult to maintain.

    Code:
    double account::make_deposit ( double howmuch ) 
    {
       return m_balance += howmuch;
    }
    
    double account::make_withdrawal ( double howmuch )
    {
       return howmuch <= getBalance( ) ? 
          make_deposit( -howmuch ) : -1.0 /** error **/ ;
    }
    Why not recycle, eh?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 9
    Last Post: 03-20-2009, 05:22 PM
  2. Coding Guideline ....!!
    By imfeelingfortun in forum Tech Board
    Replies: 8
    Last Post: 10-08-2006, 07:09 AM
  3. Before Coding
    By cyberCLoWn in forum C++ Programming
    Replies: 16
    Last Post: 12-15-2003, 02:26 AM
  4. Coding Contest....
    By Koshare in forum A Brief History of Cprogramming.com
    Replies: 46
    Last Post: 10-14-2001, 04:32 PM