• 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!

Reply to: Beginners C#query

Collapse

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "Beginners C#query"

Collapse

  • RasputinDude
    replied
    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.

    Leave a comment:


  • Scrag Meister
    replied
    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.

    Leave a comment:


  • Sysman
    replied
    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."

    Leave a comment:


  • RasputinDude
    replied
    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.

    Leave a comment:


  • doodab
    replied
    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.

    Leave a comment:


  • VectraMan
    replied
    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.

    Leave a comment:


  • doodab
    replied
    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.

    Leave a comment:


  • minestrone
    replied
    What i'm really fecked off about just now is the uncle bob clean code brigade that seem to have swept through the code bases i'm working on just now.

    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.

    What I keep finding is classes with one public method and a dozen private methods called by the public method. The class becomes an API splodge.

    Uncle bob says that is right and Uncle Bob needs a kick in the nads.

    I'm going to get started on anemic domain models next.

    Leave a comment:


  • adubya
    replied
    Originally posted by minestrone View Post
    Not in that context.

    iRows is going to be the same with ++ appended or prepended when it comes to the next line

    I would have written it...

    using (StreamReader sr = new StreamReader(args[0]) {
    while ( sr.ReadLine() !=null) {
    Console.WriteLine(iRows++ + " - " + sr.ReadLine() );
    }
    That would give a different result to what the original code produced however

    I see this kind of tulip all the time
    Last edited by adubya; 10 November 2012, 08:55.

    Leave a comment:


  • minestrone
    replied
    Originally posted by doodab View Post
    It was methods that return null when they should throw an exception. Getters that return null because the underlying value is null are perfectly sensible. A List sort() or add() method or a Document parse() method or a factory create method that returns null because it didn't work for some reason is very very not fine.
    Agree.

    Leave a comment:


  • doodab
    replied
    Originally posted by minestrone View Post
    You are mixing this, first off it was methods, now you are using a creational factory methods in you example.

    Grey Goose has been consumed tonight, shall come back to this again.
    It was methods that return null when they should throw an exception. Getters that return null because the underlying value is null are perfectly sensible. A List sort() or add() method or a Document parse() method or a factory create method that returns null because it didn't work for some reason is very very not fine.

    Leave a comment:


  • minestrone
    replied
    Originally posted by doodab View Post
    Yes, which is why if you return null when you should have thrown an exception you are doing a bad thing.

    Thingy thingy = ThingyFactory.createThingy() should not require me to check I have a valid reference to a thingy if a thingy couldn't be created.
    You are mixing this, first off it was methods, now you are using a creational factory methods in you example.

    Grey Goose has been consumed tonight, shall come back to this again.

    Leave a comment:


  • doodab
    replied
    Originally posted by minestrone View Post
    I believe exceptions are there for when something goes wrong
    Yes, which is why if you return null when you should have thrown an exception you are doing a bad thing.

    Thingy thingy = ThingyFactory.createThingy() should not require me to check I have a valid reference to a thingy if a thingy couldn't be created.

    Leave a comment:


  • minestrone
    replied
    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.
    I think always return null.

    I believe exceptions are there for when something goes wrong, I don't think user.getFirstName() should chuck an exception if the user has no first name.

    What does piss in my soup is collections being returned as null, pass me back an empty collection if there is nowt in it.

    Leave a comment:


  • minestrone
    replied
    Originally posted by Scrag Meister View Post
    Thanks so much for the replies.

    Minestrone, sorry hasty on the neg, I think the some total of your contributions was worth a +ve, even if bits of your code didn't do what mine did. . Will correct in due course.

    P.S. There is a LOT more data manipulation code in the loop I just cleared it out to make clear the bit I was asking about. Performance is important but not THAT important in this situation.

    Thank you all again.
    Don't worry about it, I was fookin hammered the previous night with football related activity, I gave it a "aw naw, made a tit out of myself there" face palm gesture about 60 seconds after posting.

    Leave a comment:

Working...
X