• (cs) in reply to frits

    Sometimes you just get so slammed that it doesn't even occur to you to come to this site. It happens to me for a week or so at a time.

    I hope he comes back, though, because boog is awesome. I would mourn his loss like I would mourn yours, frits.

  • (cs) in reply to frits
    frits:
    Nagesh:
    i am allmost positive fake nagesh is opereted by frits or boog.
    Based on what evidence? I like your posts, and fake Nageshes' as well, even if you don't like mine. Also, boog hasn't posted any comments in a month or more AFAIK. I think someone hurt his boo boo, or he is just over it, or has more important things to do.

    BTW- Who is frits, but a registered sock puppet anyway?

    Evidence is clearly steming from sixth sense that I develop after spending 1 year at camp for speshul gifted children.

    Where is boog boy and what is sock pupet?

  • Ken B. (unregistered)
    "This is one of the reasons our average .cs codefile hovers in the 22,000 lines-of-code range."
    Wow. And I thought that our largest feature-creeped module of 7,412 lines of C was huge.
  • (cs) in reply to Ken B.
    Ken B.:
    "This is one of the reasons our average .cs codefile hovers in the 22,000 lines-of-code range."
    Wow. And I thought that our largest feature-creeped module of 7,412 lines of C was huge.
    Both code sizes are preposterously gargantuan in any language, but at least C has a hundred different scenarios where it might be justfied. Embedded wooden xml blah blah.
  • (cs) in reply to hoodaticus
    hoodaticus:
    Sometimes you just get so slammed that it doesn't even occur to you to come to this site. It happens to me for a week or so at a time.

    I hope he comes back, though, because boog is awesome. I would mourn his loss... <snipped bromance>

    QFT

  • (cs) in reply to Guerilla
    Guerilla:
    Once again, you impress me as some sort of Dickwad.
    We're all dickwads here. Stop being so jealous of Matt for being better at it than you are. Maybe you and I could form a support group for dealing with our raging Westwood envy.
  • (cs) in reply to talentless_newbie (too lazy to log in properly)
    talentless_newbie (too lazy to log in properly):
    Even if the original coder came from a purely procedural background (and I admit, I did, too), surely it should have occurred to them to wrap all of those into a structure, one would think.

    If you have 45 'out' parameters in one method, if you don't at least wonder whether there is a better way pass around and manipulate stuff, you should give up and go back to being an enduser.

    I've looked around all of my embedded code, written in C, and there are no functions that take more than 5 parameters. That's as much as reliably fits into the registers in the calling convention that platform is using. Coincidentally, of course ;)

    But this isn't the whole truth. The median number of parameters is two, and I have only 4 functions across perhaps 25 kloc that do take 5 parameters. Those functions could take a struct instead, but I really don't feel like changing them as they're written in assembly and all I'd be doing is loading stuff from the struct into the registers...

  • (cs) in reply to hoodaticus
    hoodaticus:
    Guerilla:
    Once again, you impress me as some sort of Dickwad.
    We're all dickwads here. Stop being so jealous of Matt for being better at it than you are. Maybe you and I could form a support group for dealing with our raging Westwood envy.
    Maybe it's just the brain damage talking, but "raging Westwood envy" may be taken in a different way then you meant...
  • (cs) in reply to Eternal Density
    Eternal Density:
    One of the strangest things I saw was chunks of FORTRAN code in a .cs file (retained to give context) not commented out, but rather prevented from compiling with #if.
    That's... interesting. So he knows compiler directives but not /**/?
  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    hoodaticus:
    Guerilla:
    Once again, you impress me as some sort of Dickwad.
    We're all dickwads here. Stop being so jealous of Matt for being better at it than you are. Maybe you and I could form a support group for dealing with our raging Westwood envy.
    Maybe it's just the brain damage talking, but "raging Westwood envy" may be taken in a different way then you meant...
    It's baiting, I know, but there's a small - and really creepy - side to my sense of humor that actually enjoys the zune.
  • The Poop... of DOOM! (unregistered) in reply to hoodaticus
    hoodaticus:
    The Poop... of DOOM!:
    hoodaticus:
    ObiWayneKenobi:
    Don't get me wrong. I think static methods have their uses, typically in what DDD people call the "Service" - components that *only* do input/output on something, but aren't directly related to any one entity or domain concept.

    That said even then I would prefer to use instance methods to use Dependency Injection/IoC, but having a static class that acts as a "broker" or possibly as a Factory pattern implementation is okay with me. I've used static methods in Factories that simply construct a domain object from some type of raw data.

    Having a single file with half a dozen classes inside that file, all of which have static methods, however, is blasphemy and anyone who does it should be fired immediately for being a clueless Mort; it shows not only no understanding of OOP but no understanding of component design.

    +5. It's not statics that are evil. It's the exclusive use of stateless classes to prove true the axiom "You can do FORTRAN in any language."
    Yup, did similar and I don't regret it. Code that has to access an external web service, pull in an XML file, cut it into little objects, transform it into another XML file and pass that on to another external web service. As there's no point in instantiating the connection, I made it a static class. Pass in the connection data once (as it simply isn't going to change during the procedure, and the other service used a completely different way of connecting, so couldn't reuse it), and then just call the functions. There's no point in instantiating something like that.
    First of all, it sounds like you're doing XML transformations wrong.

    Second of all, you aren't likely to figure out the benefits of using OOP here until you actually do it.

    My ActiveDirectory class didn't start out all advanced with every bell and whistle. But because I didn't make it a static class, I was able to grow it over time into the feature-packed, performant beauty of OO design that it is today.

    To get the same functionality I ended up eventually needing in my ActiveDirectory class using a static class would have required dozens or hundreds of static methods. It's a lot less ugly when those methods are bound to data rather than using spaghetti code/static classes.

    OOP is a good thing. I have never once written a stateless class (other than extension methods).

    On to your example. XML receipt, processing, and transmitting is one of the most common things you have to do today. I went the other direction than you and made my own Xml namespace with classes like Post<T>, ElementDispatcher<T>, and ElementAction<T> (although that last one is a struct) to encapsulate the whole process.

    Now all my streaming XML parsing is generic + generalized, and I will never, ever write that code again. But you will. All I have to do is specify endpoints, elements, and the lambdas that act on the elements in the XML stream and the target T that will be modified by those lambda statements.

    OOP is better than what we had before. You will get much further with it than you will by regressing back to the most primitive programming techniques.

    Addendum (2011-09-29 09:30): And by "never once written a stateless class", I am not referring to SOA. SOA might get away with statelessness, although all of my RESTful work still caches behind the scenes...

    It started out as a bunch of loose PHP functions, but since

    1. it quickly became impossible to debug and maintain, and
    2. it had to become flexible enough to take one web service out and replace it with another I switched to classes. They were first very simple ones, basically just grouping all the functions into classes, with the necessary variables. Then took out the stuff I didn't want with each and every single instance (I sure as hell didn't want to create a connection to an external server for every single object).

    The reason I did the whole XML handling like this, was (again) because you had to be able to take out one web service and replace it with another. Since not all services use XML (I'm not even sure anymore if the second one did, or if it was an API they offered), I let the web service's class get the data and transfer it into the object, then the other web service's class'd get the object and transfer it into whatever form it required.

    Add to that that it had to be possible to queue these (had to also happen during cron runs), I'd say storing a serialized object'd be simpler than storing an XML file with all the elements you'd be treating (data of 1 object vs. data of all objects in the database)

    Of course, if there's a better way to do this, I'm all ears

  • (cs) in reply to Kuba
    Kuba:
    I've looked around all of my embedded code, written in C, and there are no functions that take more than 5 parameters. That's as much as reliably fits into the registers in the calling convention that platform is using. Coincidentally, of course ;)

    But this isn't the whole truth. The median number of parameters is two, and I have only 4 functions across perhaps 25 kloc that do take 5 parameters. Those functions could take a struct instead, but I really don't feel like changing them as they're written in assembly and all I'd be doing is loading stuff from the struct into the registers...

    LOL! You know you're good with five parameters. Parameter consolidation into objects or structs has way fewer advantages if you aren't working in an OO assembly language like MSIL. With OOP, those consolidated parameters may one day evolve into visitors and then actually become a high-quality design.

    But it makes no sense whatsoever to do this in machine code where you'd have to manage memory, and a struct has no methods anyway in machine code (so it could never be a visitor anwyay, unless you stashed a function pointer in the struct...). The end result of applying high-level concepts to low level languages is that you end up re-writing high level languages and doing a shittier job at it.

  • z00n3s!$ (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    hoodaticus:
    Guerilla:
    Once again, you impress me as some sort of Dickwad.
    We're all dickwads here. Stop being so jealous of Matt for being better at it than you are. Maybe you and I could form a support group for dealing with our raging Westwood envy.
    Maybe it's just the brain damage talking, but "raging Westwood envy" may be taken in a different way then you meant...
    Very funny. //U\\ I doubt anyone else here is as immature as you are. (.) (.) I think you're projecting. 8===P

    gasps for air PPPPEEEEEEEEEEENNNNNNNNNNNSISISISISISISISSSSSSS!!!!!!!!!

  • (cs) in reply to hoodaticus
    hoodaticus:
    C-Octothorpe:
    hoodaticus:
    Guerilla:
    Once again, you impress me as some sort of Dickwad.
    We're all dickwads here. Stop being so jealous of Matt for being better at it than you are. Maybe you and I could form a support group for dealing with our raging Westwood envy.
    Maybe it's just the brain damage talking, but "raging Westwood envy" may be taken in a different way then you meant...
    It's baiting, I know, but there's a small - and really creepy - side to my sense of humor that actually enjoys the zune.
    Hey, you never answered my question BTW...

    Where or when would you consider it acceptable to use static classes or static methods? I just don't follow the "OMG, you're a moron if you use static anything!" logic.

    If you've ever stepped through .Net framework code, you'll see an abundance of static methods and classes like the Convert and Math classes, or int.Parse, int.TryParse, etc. etc., not to mention several "helper" classes I've come across in ASP.Net (like HttpUtility which should be static, but instead is sealed and filled with only static methods).

    I really think a statement like "if I see static methods/classes, I'll need to teach the dev OOP" is very broad, and is wrong IMO...

    I am, however, always open to other points of view, as long as it's backed up with a decent explanation.

  • Ken B. (unregistered) in reply to hoodaticus
    hoodaticus:
    Eternal Density:
    One of the strangest things I saw was chunks of FORTRAN code in a .cs file (retained to give context) not commented out, but rather prevented from compiling with #if.
    That's... interesting. So he knows compiler directives but not /**/?
    It depends on the length of the FORTRAN block, and whether or not such a block might contain "*/" in it for some reason.
  • I. G. E. (unregistered) in reply to hoodaticus
    hoodaticus:
    Eternal Density:
    One of the strangest things I saw was chunks of FORTRAN code in a .cs file (retained to give context) not commented out, but rather prevented from compiling with #if.
    That's... interesting. So he knows compiler directives but not /**/?
    Not necessarily. It may be easier to read if #if'ed instead of commented out, depending on the syntax highlighter. Although, I don't think FORTRAN highlighted C#-style works too well.
  • (cs) in reply to Ken B.
    Ken B.:
    "This is one of the reasons our average .cs codefile hovers in the 22,000 lines-of-code range."
    Wow. And I thought that our largest feature-creeped module of 7,412 lines of C was huge.

    I can top that. Not in LOC but, we have a 6,000 line C# file. Some highlights:

    • There is one file, that for some odd naming convention starts with an underscore to differentiate it (e.g. "_MyClass.cs" although it's named a tiny bit better than that)
    • That file contains 13 different classes representing anything from DTOs to Services to business logic. 13 classes all in one file, I guess to keep them grouped together (because Namespaces or logical folders are too hard).
    • THERE ARE GOTO STATEMENTS that are "core logic". Yes, fucking GOTO statements in C# 3.5. Which are also copied and pasted in several methods.
  • (cs) in reply to The Poop... of DOOM!
    The Poop... of DOOM!:
    Of course, if there's a better way to do this, I'm all ears
    Well, now I'm not so sure. If you were going from XML to XML you should use XSLT if it's a simple transformation, but if you weren't then there's no need. It just sounded to me like you were writing your own XML transformer, which would be something of a WTF.

    I haven't done enough PHP to know how thoroughly oop-ified it is, but my long-term design goal would be to develop a domain object model that generically describes:

    1. connections to endpoints a) Uri b) Protocol (XML, JSON, MTOM, whatever)
    2. requests a) Protocol b) Writing (I have my request class provide a function to the connection object so that the connection can write the request when it's time)
    3. responses a) Protocol b) Parsing engine (two ways I've found to do this: parser creates the object(s) you're trying to get, or parser modifies the object(s) you already instantiated. Modification is much, much easier to get right).

    Make the classes above abstract and then just provide concrete implementations when you need them. It's way more extensible than procedural-style static methods. It lets you share the code everywhere, optimize the hell out of the internals over time, and add new functionality to the natural growth points in your object model.

    OOP is all about simultanously managing and encouraging the growth and improvement of your code base.

  • (cs) in reply to Ken B.
    Ken B.:
    "This is one of the reasons our average .cs codefile hovers in the 22,000 lines-of-code range."
    Wow. And I thought that our largest feature-creeped module of 7,412 lines of C was huge.
    I used to maintain a project in MFC C++ that had a header file with 20,000 SLOC and a corresponding .cpp file with 40,000 SLOC.

    Addendum (2011-09-29 11:09): There was a 7.5 step process for adding new menu items that was only documented in comments across the code base. Why 7.5 steps you ask? Well there used to be 7, but the original programmer has to added a step between 2 and 3 (step 2.5). This is the high quality code you get when you pay $100 an hour to consultants. That rate applied to the time she spent in the bathroom crying after the department manager criticized her code/and or progress.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Ken B.:
    "This is one of the reasons our average .cs codefile hovers in the 22,000 lines-of-code range."
    Wow. And I thought that our largest feature-creeped module of 7,412 lines of C was huge.

    I can top that. Not in LOC but, we have a 6,000 line C# file. Some highlights:

    • There is one file, that for some odd naming convention starts with an underscore to differentiate it (e.g. "_MyClass.cs" although it's named a tiny bit better than that)
    • That file contains 13 different classes representing anything from DTOs to Services to business logic. 13 classes all in one file, I guess to keep them grouped together (because Namespaces or logical folders are too hard).
    • THERE ARE GOTO STATEMENTS that are "core logic". Yes, fucking GOTO statements in C# 3.5. Which are also copied and pasted in several methods.
    if (code.ToLowerInvariant().Contains("goto")) goto hell;
  • (cs) in reply to frits
    frits:
    Ken B.:
    "This is one of the reasons our average .cs codefile hovers in the 22,000 lines-of-code range."
    Wow. And I thought that our largest feature-creeped module of 7,412 lines of C was huge.
    I used to maintain a project in MFC C++ that had a header file with 20,000 SLOC and a corresponding .cpp file with 40,000 SLOC.

    Addendum (2011-09-29 11:09): There was a 7.5 step process for adding new menu items that was only documented in comments across the code base. Why 7.5 steps you ask? Well there used to be 7, but the original programmer has to added a step between 2 and 3 (step 2.5). This is the high quality code you get when you pay $100 an hour to consultants. That rate applied to the time she spent in the bathroom crying after the department manager criticized her code/and or progress.

    That is about the most fucked up thing I've ever heard!

    Holy shit! What could possibly excuse so much MFC code? Does she not want to use methods she's already used somewhere else because they're "used" and not brand new or something?

  • (cs) in reply to hoodaticus
    hoodaticus:
    frits:
    Ken B.:
    "This is one of the reasons our average .cs codefile hovers in the 22,000 lines-of-code range."
    Wow. And I thought that our largest feature-creeped module of 7,412 lines of C was huge.
    I used to maintain a project in MFC C++ that had a header file with 20,000 SLOC and a corresponding .cpp file with 40,000 SLOC.

    Addendum (2011-09-29 11:09): There was a 7.5 step process for adding new menu items that was only documented in comments across the code base. Why 7.5 steps you ask? Well there used to be 7, but the original programmer has to added a step between 2 and 3 (step 2.5). This is the high quality code you get when you pay $100 an hour to consultants. That rate applied to the time she spent in the bathroom crying after the department manager criticized her code/and or progress.

    That is about the most fucked up thing I've ever heard!

    Holy shit! What could possibly excuse so much MFC code? Does she not want to use methods she's already used somewhere else because they're "used" and not brand new or something?

    It wasn't even "real" MFC. It was a blank window that was drawn on using DirectX 2D drawing routines in 256 color in fullscreen mode. That also wasn't the full code base. That was just the collection of custom menu items. Each menu item was a separate subtype and almost all of the logic was implemented inline. Basically is was a steaming pile of "magic button" anti-patterns.

    More WTFs:

    • This was for a measurement instrument that had two channels. Code related to channels had no less than 100 distinct checks for which channel we were on. ie.

      if(chan == CHAN_1)

    • The code was littered with checks like:

      if(result == TRUE){}
      Where TRUE is macro defined as 1 and the result could be several non-zero return values.
    • Several thousand line methods with multiple returns and gotos and inline comments that were 50 lines of justification for whatever crappy things they were doing that robbed screenspace and made things less clear than no comments at all. I wish I saved some of those comments because I remember some of them were pretty funny.

  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    Where or when would you consider it acceptable to use static classes or static methods?
    I have no problem with static methods - I use them all the time. I take issue with static classes that aren't used for extension methods. They are by definition procedural programming, which under conditions of growth leads to spaghetti code.

    I prefer spaghetti-and-meatball code, where the spaghetti is bound to meatballs (data / state) and meatballs are connected to each other with spaghetti.

    I disagree with Microsoft's use of Interlocked, Math, and Convert as static classes. They could have made them instance methods - which is ideal - or they could have made them extension methods if they found their intellisense member list getting too big, as they did with LINQ.

    Every time I ever thought about writing a static class, it took no more than ten seconds for me to see how an object-oriented approach would be superior. If there is no conceivable state other than through types I don't own, I make them extension methods.

  • (cs) in reply to frits
    frits:
    More WTFs: * This was for a measurement instrument that had two channels. Code related to channels had no less than 100 distinct checks for which channel we were on. ie.
    if(chan == CHAN_1)
    • The code was littered with checks like:

      if(result == TRUE){}
      Where TRUE is macro defined as 1 and the result could be several non-zero return values.
    • Several thousand line methods with multiple returns and gotos and inline comments that were 50 lines of justification for whatever crappy things they were doing that robbed screenspace and made things less clear than no comments at all. I wish I saved some of those comments because I remember some of them were pretty funny.

    One day, Stroustrup's ghost is going to systematically find these people, possess them, leap them out a window, and repeat.

  • Nagesh (unregistered) in reply to hoodaticus
    hoodaticus:
    C-Octothorpe:
    Where or when would you consider it acceptable to use static classes or static methods?
    I have no problem with static methods - I use them all the time. I take issue with static classes that aren't used for extension methods. They are by definition procedural programming, which under conditions of growth leads to spaghetti code.

    I prefer spaghetti-and-meatball code, where the spaghetti is bound to meatballs (data / state) and meatballs are connected to each other with spaghetti.

    I disagree with Microsoft's use of Interlocked, Math, and Convert as static classes. They could have made them instance methods - which is ideal - or they could have made them extension methods if they found their intellisense member list getting too big, as they did with LINQ.

    Every time I ever thought about writing a static class, it took no more than ten seconds for me to see how an object-oriented approach would be superior. If there is no conceivable state other than through types I don't own, I make them extension methods.

    In university, we learn this being leads to improper dependance between types. Halfing intermetiairy type to manag relationsihp is best coarse. Type not halfing stait data, so using static also being best coarse.

  • Matt Westwood (unregistered)

    What does it take to get a ****ing article around here?

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    What does it take to get a ****ing article around here?
    Maybe if you weren't such a useless mick cunt, he'd chuck us one our way...

    ducks

  • Jay (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    eVil:
    The Great Lobachevsky:
    Yeah, there aren't any women in computers, right? At least any that know JavaScript. ;-)

    Got to the right websites, and you'll find your computer is chock-full of them. They generally naked and licking each other though, so I doubt they have much time for JavaScript.

    The ones I found actually use "JavaScript" as a safeword. Go figure.

    That's a good idea. Mention of Javascript always kills my sex drive. Along with my will to live.

  • Remy Porter (unregistered) in reply to Matt Westwood
    Matt Westwood:
    What does it take to get a ****ing article around here?

    Come on, guys, we're having a hard time since Alex's latest untimely passing. We're working on rebooting him, and then we'll have an article up for you.

  • (cs) in reply to Jay
    Jay:
    JamesQMurphy:
    eVil:
    The Great Lobachevsky:
    Yeah, there aren't any women in computers, right? At least any that know JavaScript. ;-)

    Got to the right websites, and you'll find your computer is chock-full of them. They generally naked and licking each other though, so I doubt they have much time for JavaScript.

    The ones I found actually use "JavaScript" as a safeword. Go figure.

    That's a good idea. Mention of Javascript always kills my sex drive. Along with my will to live.

    This. Javascript is what outsourcing is for.

  • Somebody (unregistered) in reply to Global

    MY EYES!!!!!

  • (cs) in reply to Nagesh
    Nagesh:
    hoodaticus:
    C-Octothorpe:
    Where or when would you consider it acceptable to use static classes or static methods?
    I have no problem with static methods - I use them all the time. I take issue with static classes that aren't used for extension methods. They are by definition procedural programming, which under conditions of growth leads to spaghetti code.

    I prefer spaghetti-and-meatball code, where the spaghetti is bound to meatballs (data / state) and meatballs are connected to each other with spaghetti.

    I disagree with Microsoft's use of Interlocked, Math, and Convert as static classes. They could have made them instance methods - which is ideal - or they could have made them extension methods if they found their intellisense member list getting too big, as they did with LINQ.

    Every time I ever thought about writing a static class, it took no more than ten seconds for me to see how an object-oriented approach would be superior. If there is no conceivable state other than through types I don't own, I make them extension methods.

    In university, we learn this being leads to improper dependance between types. Halfing intermetiairy type to manag relationsihp is best coarse. Type not halfing stait data, so using static also being best coarse.
    Hence, extension methods.

  • z00n3s!$ (unregistered) in reply to Jay
    Jay:
    Mention of Javascript always kills my sex drive. Along with my will to live.
    Yeah, I hate it when I'm in the mood and then suddenly she blurts out - "What's the deal with dynamic typing!?!" I just sigh and push an air-filled syringe into my neck.
  • (cs) in reply to hoodaticus
    hoodaticus:
    Hence, extension methods.
    But extension methods can only be used on non-null objects/structs, which means state...

    What you're arguing (extension methods) is a personal preference or style, which is valid, but nothing to do with whether or not you should use static methods or classes.

    I do see the value in extension methods, but to me they're an extension of the developers personal style, which according to best practice and your very own words, should never exist in code. You should never be able to look at code and say "hoodaticus wrote this because there's fucking extension methods all over the place". Also, unless you wrote them yourself, they can waste other developers time because they're not defined in the same place/code-file as the type itself.

    Also, other than the CLR doing this magic for you, what is different in your implementation than mine? At the end of the day all you have is a static class filled to the brim with static methods...

  • Timmy (unregistered) in reply to TheSHEEEP
    TheSHEEEP:
    hoodaticus:
    Procedural coders should be banned from .NET development.

    They should be banned from pretty much anything. Just to be sure.

    Except crochet.

    In every language, even C and assembler? Why? What do you think is behind all those methods? There's no such thing as magic--somewhere in the object method is procedural code. Sure, it's at a lower level and it's compiled and blah, blah...but somebody's got to code it. Is there some magic assembler code that does everything all in one line? Just magic?

    It's like those self-described guru's who see a nested IF block that's easy to read and maintain, but says "I can put this all on one line", the result being a ridiculous mess of OR's and parens, etc, stretching out to the right so far we have to scroll to see it, and nobody can really understand the actual purpose of what it's doing or how to make and adjustment if one is needed--regardless of how well someone thinks they've commented it.

  • (cs) in reply to Timmy
    Timmy:
    TheSHEEEP:
    hoodaticus:
    Procedural coders should be banned from .NET development.

    They should be banned from pretty much anything. Just to be sure.

    Except crochet.

    In every language, even C and assembler? Why? What do you think is behind all those methods? There's no such thing as magic--somewhere in the object method is procedural code. Sure, it's at a lower level and it's compiled and blah, blah...but somebody's got to code it. Is there some magic assembler code that does everything all in one line? Just magic?

    It's like those self-described guru's who see a nested IF block that's easy to read and maintain, but says "I can put this all on one line", the result being a ridiculous mess of OR's and parens, etc, stretching out to the right so far we have to scroll to see it, and nobody can really understand the actual purpose of what it's doing or how to make and adjustment if one is needed--regardless of how well someone thinks they've commented it.

    Timmy, Pls don't make post again!

    Thx, Nagesh.

  • Nagesh (unregistered) in reply to Nagesh
    Nagesh:
    Timmy:
    TheSHEEEP:
    hoodaticus:
    Procedural coders should be banned from .NET development.

    They should be banned from pretty much anything. Just to be sure.

    Except crochet.

    In every language, even C and assembler? Why? What do you think is behind all those methods? There's no such thing as magic--somewhere in the object method is procedural code. Sure, it's at a lower level and it's compiled and blah, blah...but somebody's got to code it. Is there some magic assembler code that does everything all in one line? Just magic?

    It's like those self-described guru's who see a nested IF block that's easy to read and maintain, but says "I can put this all on one line", the result being a ridiculous mess of OR's and parens, etc, stretching out to the right so far we have to scroll to see it, and nobody can really understand the actual purpose of what it's doing or how to make and adjustment if one is needed--regardless of how well someone thinks they've commented it.

    Timmy, Pls don't make post again!

    Thx, Nagesh.

    You are the one to be asking stop to post! On second thinking, post pasword you changed for haked acount, matterhorn. Post only pasword and no thing more!!!

  • (cs) in reply to Nagesh

    Fake Nagesh, Chullu bhar paani mein doob jao!

  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    what is different in your implementation than mine? At the end of the day all you have is a static class filled to the brim with static methods...
    I don't care about static methods. What bothers me is people using procedural programming when using OOP is so much better.

    With System.Math, OOP is not demonstrably better, so I don't mind it so much. But Active Directory is an object store of gargantuan proportions, with numerous methods and innumerable properties and nesting and yada yada. It's practially made for an OO solution.

    Originally, all I needed was to look up a display name from a user name. I knew that Active Directory is a big topic and might need more functionality one day, so I resisted the urge to make a static class. I made a second class ActiveDirectoryUser to hold per-user data, with ActiveDirectory as the factory. Now when I need to authenticate a user, I just add a GetIsAuthenticated method to the user object. It grows over time.

    Yeah, you can do all that with statics. Now add this wrinkle:

    Make it work for a domain other than the one you're on.

    Uhoh! Now I get to copy-pasta all my static methods to overload them with a domainName parameter.

    Now data bind the list of all users to a ComboBox.

    Okay, so now I need a GetUserStringList static method.

    Now let someone select that user and reset that password from the ComboBox.

    Gosh, this would be a whole lot easier if the ComboBox list items were bound to an actual object that has a ResetPassword method, wouldn't it? Instead of chaining a bunch of static method calls together?

    It's not a matter of preference. If you start out with a static class, you will either throw it away when you need more out of it and replace it with a proper API, or you will add spaghetti, or you will simply leave the problem unsolved. Instance classes were invented to solve the latter problems.

    With the amount of time required to start the OO solution not being significantly different from making a procedural solution, I go with OO every time. I really didn't think this would be even remotely controversial.

    Since you and I usually agree on everything, I'm going to assume my lack of communication skills is at fault for our disagreement. I'm looking at this from the perspective of someone who has never written a static class and has seen them used as escape hatches by ALL BUT ONE of my developers so that they don't have to use OOP. The one good developer and I both sneer at Util classes because, to quote him, "they're not object oriented".

    I don't know where you're coming from, which is probably where this conversation got derailed.

    Addendum (2011-09-29 14:35): There are exceptions for everything. Nagesh brought up a good point about decoupling. If cross-namespace coupling bothered me, I would either put the coupling code in only one of the namespaces, merge the namespaces, or provide a static class to handle the conversion (if the conversion doesn't itself need OOP patterns for extensibility). So it is sometimes the answer - but I have never seen anyone do it, because most people just aren't that good.

    +5 for Nagesh?

  • Nagesh (unregistered) in reply to hoodaticus
    hoodaticus:
    +5 for Nagesh?
    Thanking yuo for point of Internets!
  • (cs) in reply to hoodaticus
    hoodaticus:
    I don't care about static methods. What bothers me is people using procedural programming when using OOP is so much better.
    Ahh, there's the disconnect... My ADD is acting up again. I got tunnel vision when you said there are no circumstances when you should ever use static classes or methods, other than extension methods.
    hoodaticus:
    With System.Math, OOP is not demonstrably better, so I don't mind it so much. But Active Directory is an object store of gargantuan proportions, with numerous methods and innumerable properties and nesting and yada yada. It's practially made for an OO solution.
    Agreed.
    hoodaticus:
    <ton of examples specific to your domain problem(s)>
    Again, I agree, and sometimes an escape hatch isn't that bad when you have a crazy tight timeline and you know what you're writing will be thrown away in several weeks or months. I guess the sticking point is that there is a difference between those that misuse static classes and KNOW they're bad/cheating, and those that use them as a crutch/regular practice.

    Plus your implication that anybody would need to teach me OOP pissed me right off. :)

    My bad, we do agree.

  • Nagesh (unregistered) in reply to Nagesh
    Nagesh:
    Fake Nagesh, Chullu bhar paani mein doob jao!
    Senti, tu asino. Riesco ad usare strumenti di traduzione troppo!
  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    Matt Westwood:
    What does it take to get a ****ing article around here?
    Maybe if you weren't such a useless mick cunt, he'd chuck us one our way...

    ducks

    Nope, that wasn't me (a) it said "unregistered" on the username, (b) I wouldn't use **** for fuck, and (c) most important, boyo, useless cunt I don't argue with, but I'm not a mick I'm a fucking taff, look you.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    What does it take to get a ****ing article around here?

    Yeah, come to think of it, what does it take to get a cunting article around here?

  • (cs) in reply to C-Octothorpe

    I told you my communications skills were to blame :). That would have pissed me off too! I apologize.

    Like I said elsewhere, rules aren't for good developers - they're for bad ones. You are definitely in the "good" category. You're a rule maker - someone who should be listened to - not a follower.

    For reasons why static classes are actually good and can increase the encapsulation of your non-static classes, see here. Although, he's only talking encapsualtion, while I'm taling about APIs in general.

  • (cs) in reply to hoodaticus
    hoodaticus:
    I told you my communications skills were to blame :). That would have pissed me off too! I apologize.
    No worries! Like I said, sometimes I'll just hear just part of what's being said and focus on that rather than the whole argument, which you presented very well and I agree with...

    Just today only I've had at least 3 head-desks because the person who I inherited the code from couldn't even spell OOP...

  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    The person who I inherited the code from couldn't even spell OOP...
    ZOMG! LOL! I'm stealing that!
  • tristique (unregistered)

    Abandon hope, all ye who hope for an article today.

    This always happens at the worst times. Things are slow...I just spent the last 30 minutes cleaning out my inbox, and the only thing I have to come back to is C-Octothorpe and hoodaticus making out.

  • (cs) in reply to tristique
    tristique:
    Abandon hope, all ye who hope for an article today.

    This always happens at the worst times. Things are slow...I just spent the last 30 minutes cleaning out my inbox, and the only thing I have to come back to is C-Octothorpe and hoodaticus making out.

    Jealous?

  • trtwtf (unregistered) in reply to hoodaticus
    hoodaticus:
    tristique:
    Abandon hope, all ye who hope for an article today.

    This always happens at the worst times. Things are slow...I just spent the last 30 minutes cleaning out my inbox, and the only thing I have to come back to is C-Octothorpe and hoodaticus making out.

    Jealous?

    If you two are quite finished, there's still fifteen minutes before five o'clock. Nagesh isn't just going to bash himself, you know!

Leave a comment on “The Global Workaround”

Log In or post as a guest

Replying to comment #361666:

« Return to Article