• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Beginners C#query

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #41
    Originally posted by minestrone View Post
    Sometimes, despite trying to push functionality into classes where that should belong in you just have to write a long winded method to do a process, maybe a 150 liner but I think that if you name the method correctly and comment it out correctly I'm good with that.
    Yes, blindly applying rules is counterproductive, you need to understand what motivates them. Smaller methods increase readability as long as code is broken out for logical reasons (reuse, ease of unit testing) but just breaking it into 30 line blocks "because that's the rule" is numpty thinking.

    A better rule might be "if you cant cope with more than a screenful of code at a time you shouldn't be a programmer"
    Last edited by doodab; 10 November 2012, 10:32.
    While you're waiting, read the free novel we sent you. It's a Spanish story about a guy named 'Manual.'

    Comment


      #42
      Originally posted by doodab View Post
      Of course one reason you have to put return values into a variable rather than use them directly is that people writing the methods often return null when they should have thrown an exception so you need to check the value before you use it. This gets on my tits.
      In C++ you can return a reference from a function, and a C++ reference can never be null. The only way out of the function other than returning a valid result is to throw an exception.

      Of course if you can catch the null reference exception, you don't necessarily need to test the return value everywhere. It's a bit hacky, but the end result is the same.
      Will work inside IR35. Or for food.

      Comment


        #43
        Originally posted by VectraMan View Post
        It's a bit hacky, but the end result is the same.
        Not if the end result of anything going wrong is a null pointer exception + stack trace in the log file rather than a meaningful error message.
        While you're waiting, read the free novel we sent you. It's a Spanish story about a guy named 'Manual.'

        Comment


          #44
          Sometimes, despite trying to push functionality into classes where that should belong in you just have to write a long winded method to do a process, maybe a 150 liner but I think that if you name the method correctly and comment it out correctly I'm good with that.
          I kid you not on this.

          I had to review a permie's code a few years ago and there were five functions that were called sequentially:

          Code:
          x = DoPart1()
          x = DoPart2(x)
          x = DoPart3(x)
          x = DoPart4(x)
          x DoPart5(x)
          When I picked him up on this, his response was that he didn't like to write functions that were longer than his screen and that he didn't believe in object orientation anyway.

          That was a peachy contract, that was.

          Comment


            #45
            Originally posted by zeitghost
            There's nothing wrong with 10 page DO loops.

            Used them in FORTRAN all the time.

            Now then, what's this "object oriented" thingie you're all talking about?
            When the computer press first started wittering on about "object oriented" I ask a more experienced colleague what it was all about.

            "Just what you've been doing all along, but it's got a new name."
            Behold the warranty -- the bold print giveth and the fine print taketh away.

            Comment


              #46
              Had a fun couple of weeks so far doing C#. Done some before but always very erratic.

              Some nice functionality that wasn't in VBA to date.

              ConfigurationManger, StreamReader,

              But ObjectShredder, I would have thought taking a LINQ query and putting it into a DataTable would have been standard practice.

              Enjoying it, and being productive too.

              Learning curve 10% C#, 90% .NET Framework.
              Last edited by Scrag Meister; 14 November 2012, 12:06.
              Never has a man been heard to say on his death bed that he wishes he'd spent more time in the office.

              Comment


                #47
                Learning curve 10% C#, 90% .NET Framework.
                That's usually the case though, isn't it? Learning the syntax constraints of a language takes very little time if you're any good.

                The the framework/API is the hard thing. I tend to flit between C#, java and ++C <-- - sometimes on the same project - and the hard part is remembering all the library calls and how the different IDEs behave.

                Comment

                Working...
                X