• 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

5.00 star(s)
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: 10:27
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.
 
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.
 
There's nothing wrong with 10 page DO loops.

Used them in FORTRAN all the time. :smokin

Now then, what's this "object oriented" thingie you're all talking about? :smokin

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."
 
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: 11:31
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.
 

Advertisers

Back
Top