C#: Using accessors and private functions/variables

irishdude11

If you are working on a solo project is it a complete waste of time to use properties/accessors and private/protected keywords? Are they only useful in a group project situation?

unknownlegend

irishdude11 wrote: »

If you are working on a solo project is it a complete waste of time to use properties/accessors and private/protected keywords? Are they only useful in a group project situation?

I don't think so, you should try use best programming practice even on solo projects. This will stand in your favour when working on group projects. Look into StyleCop since you specifically mention c#. Some of the rule: I don't agree with but you can change the rule engine easily

Procasinator

It wouldn't be a complete waste of time as it means you a putting thought into the design system. It also will allow to refactor easier.

The only time it may be a complete waste of time to put much thought into is if it is a throwaway project. Such as generating a once-off report or similar activity.

Trampas

fxcop also.

Maybe your solo project could be broken down into smaller projects.

should get into a good habit of always improving on every app you write.

even if it is a tiny change but means it is better and takes longer to learn how to write the code.

don't try and cut corners even if it works.

stesh

irishdude11 wrote: »

If you are working on a solo project is it a complete waste of time to use properties/accessors and private/protected keywords? Are they only useful in a group project situation?

What?

Different access levels are pretty fundamental to object-oriented programming.

Anima

Try and write any non-trivial program with those ideas and you'll see the value of encapsulation fairly fast!

Evil Phil

Bad code is bad code, regardless of the project. If you have to do maintenance or get through some kind of quality assurance (system test/UAT) then you'll be grateful you didn't cut corners.

Colonel Panic

For classes that typically hold nothing but data, I use C#'s automatic properties. You see that all over the place.

For actual business logic code, I think it's more important to get your interfaces right even if you're banging out quick and dirty code. That way, an interface acts as a contract to whatever implementation you have under the hood. It's a good habit to get into!

But then even THAT's not too important when you start out, code evolves. A few crappily written classes can be refactored into something much bigger and be fixed while you do it.

stevenmu

I couldn't even begin to count the amount of projects that started out as some quick little utility that only I would use, but later grew into something much larger, more complex, and was widely deployed.

I learned long ago to always do it right from the start, otherwise something that was quick and simple soon becomes a huge unwieldy mess.