Hello,

I am learning more and more about oop and constantly hear programmers telling me to code to an interface etc.

If i am writing code that is not going to be reused by anyone and will only be used in my own little pruvate programs, is it overkill to implement proper oop design practices?

Surely what you do with your own little private programs is your own business?

I mean in general, is it better in the long run to develop uniform coding habits or is cutting corners harmful to a junior programmer etc?

Just asking how other people code and if all the code they write in their own time follows the rigid requirements of real world code.

I mean, would you make fields public because you cant be bothered writing accessor methods or properties?

Stuff like that.

Just working on my style foonly, you grumpy old bastard :P

onemind writes...

I mean, would you make fields public because you cant be bothered writing accessor methods or properties?

I wouldn't, because deciding whether a field should be public or not takes up so little time, it's not worth the potential problems not doing so.

Just asking how other people code and if all the code they write in their own time follows the rigid requirements of real world code.

In my opinion, "real world code", in general, is a lot less rigid than you think.

Just working on my style foonly, you grumpy old bastard :P

Pfft, I just think it's a stupid question. If you're just coding for yourself, do whatever makes you happy. If you're worried that skimping on design principles will be harmful to your programming skills, don't skimp on them.

I tend to use the same process whether I'm writing personal code or when I'm writing "real world" code:

- start off with something hideous, but working
- make it into something less hideous, and still working

The only difference is the point at which I decide to stop. I hardly ever write pristine code right off the bat -- software development for me is an iterative process. "Plan to throw one away", etc.

I can't think of any good reason to constrain yourself to some rigid framework or ideology when it's not strictly necessary to do so.

I often find when doing research and coding prototypes and test algorithms that implementing correct OO design practices just takes more time when the focus is on whether the principle itself will work. Unless the code is going to be re-used or distributed I'd say its up to you.

If it needs an interface it should have a proper purpose for doing so. Methods should have purpose too.

Your code doesn't, and shouldn't, be made up of a million methods and classes unnecessarily. And your private code doesn't have to be godly (in OOP terms). Just what you make public and where should be well thought out (The public API).

How you implement it should be hidden away. And if you want to use some private classes to help you do that, so be it. Don't waste too much time deciding on names for local variables or for things in private classes.

You don't need a million comments either. You should aim for your code to be readable without comments. Only where that is not possible should you comment above and beyond standard documentation.

There's nothing more annoying than code with a million methods that are only used once (for the sake of another method) and a thesis in every one of those methods. Well... perhaps if all those methods are defined through interfaces it could possibly be more annoying. Though I prefer not to think about such code.

Core OO design principles like interfaces & polymorphism, when applied correctly, will often make life easier for you, whether its a personal or business project. The idea isn't to apply as many OO practices & patterns to your code as possible, its about acquiring a level of understanding that allows you to instinctively know when and where they should be applied. The best way to achieve this is first reading to get a broad understanding and then putting it into practice. I'd definitely recommend for you to try and incorporate good design practices in your personal code - use it as an opportunity to hone your skills and improve your understanding of different design principles & practices.

onemind writes...

I mean in general, is it better in the long run to develop uniform coding habits or is cutting corners harmful to a junior programmer etc?

As someone who was mainly self-taught - i can tell you that i spent a long time with ad-hoc coding and cutting corners, sometimes intentional sometimes through ignorance.

Foonly writes...

If you're just coding for yourself, do whatever makes you happy. If you're worried that skimping on design principles will be harmful to your programming skills, don't skimp on them.

My personal opinion, is that while formal design techniques are very useful, that you really need experience (including the experience of screwing things up) to make the most of applying them. The degree to which they are important depends on the context.

My preference is an 'evolutionary' style of coding. What changed was that as i got more practice i got much better at actually evolving software rather than turning in into a giant tangled mess :)

I also like to prototype, i think you find 'hidden' problems much faster and in a way that gives you more insight into the problem, and being in a position to make informed decisions about the best approach.

Code is never perfect, and you will never have the time to do all that you want. The real skill is how you make all the thousands of little decisions as to cost vs benefit. And a lot of that is just experience.

I am currently learning Java and using some code i wrote back in 1989 to help.

its just the traditional 4 player mahjong game in Visual basic 4.0, only 2400 lines.

Problem is, no comments or anything about what arrays hold, what flags! hold what etc.

My thinking at the time was "quick and dirty", as long as it works.

Sure i can follow the logic in the code by looking at teh code, but its a time sink that could have been avoided with better design practices.

Also if you cut corners, it will become a habit.

Sqwert writes...

Also if you cut corners, it will become a habit.

I actually don't agree with that. Sometimes cutting corners is a good thing. Sometimes quick and dirty really is what is called for. It can be painful when something quick and dirty tries to become something it was never intended to be.

There's almost always some degree of corner cutting that has to happen. Cutting the wrong corners is the problem... and when you get burned by it - you will avoid it, not make it a habit!

Thanks all.

Believe it or not but that was actually helpful. :)

Cheers

my lecturer always says that if you do something out of habit, then when it comes to crunch time, when ur under pressure, you will automatically do the habituated action. Therefore, practicing best coding standards (i.e., use interfaces when ever possible), even for "little projects", will help you maintain discipline and when it counts the most, you wont make mistakes so easily.

I don't agree with your lecturer. He is right only to a degree: a person is more likely to lean on habitual behaviour but it is far from a guaranteed automatic reaction.

if im coding something like a proof of concept, then i dont worry about public, private, ect.. nor care about if its all in one class. I just want to make sure it can do what i want it regardless of how. That also means variable names are variable1, 2, ect... as long as i know what they are at the time and it can be thrown away after its satisfied my curiosity and proven its possible then its done its job. But as soon as you start the real project well you need to make sure you do name variables meaningfully, because after its done, going back and changing them is such a pain in the ass, and can introduce errors, that your gona have to debug. Your also gona have to document everything , because most managers want to generate doc's from the code.. ect.... End of the day if your getting paid for it, do it right from the start, otherwise dont do it at all, and knowingly cutting corners will ALWAYS bite you in the ass, either you manager will pull you up on it and your gona have to fix it, or worse, it gets into production and causes havock in which case your gona have to fix it and your gona get a very bad reaction very fast.

Naming local variables and private methods is a pain, and I usually give them stupid names (whatever pops into my head first) so I don't interrupt my train of thought.

Sometimes they don't end up getting changed. I still get laughed at by my colleagues for my MeatAndPotatoes() method.

Benny Lava writes...

by my colleagues for my MeatAndPotatoes() method.

hahahaha

Rob writes...

hahahaha

And now I'm getting laughed at by the internet as well.

Benny Lava writes...

Naming local variables and private methods is a pain, and I usually give them stupid names

What IDE do you use? a lot of them have refactoring (simply change the name of say a method and it replaces all the references to it with the newly changed method).. although I believe it does depend on the lanaguge (is not really possible with C++ I believe).

identitymatrix writes...

What IDE do you use?

Visual Studio, and yes it does have the refactoring. I just don't always remember to use it before something goes into production.

Benny Lava writes...

Naming local variables and private methods is a pain, and I usually give them stupid names

I actually find that factoring a block of code, even if it's small and/or only called once, to a method that has a descriptive name is actually better than having a comment around the code block.

When i'm writing C#, i make good use of the refactoring/renaming option to quickly give a better name to something if things change.

onemind writes...

I mean in general, is it better in the long run to develop uniform coding habits or is cutting corners harmful to a junior programmer etc?

As long as you're aware you're cutting corners... a good practice is to comment a particular 'hacky' block with:

//TODO: The following code is bad, what I'd really like to do...

Most IDEs understand the //TODO and //FIXME type comments and produce a list somewhere.

I mean, would you make fields public because you cant be bothered writing accessor methods or properties?

No, and this goes back to the whole concept of OO. Hide the inner workings of a class from the outside world. Code the API. Why is this important?

You can usually refactor the inner workings of the class without touching the API. This means that everything else using your classes does not need to change. If you expose variables then your outside world code becomes tightly coupled with the inner workings of your class... bad idea.

Also, you might find that your accessor and setter functions need to do something before, or perhaps after the particular property of the class is accessed - having these functions in place allows you to encapsulate access at any point in the software's life.

onemind writes...

If i am writing code that is not going to be reused by anyone and will only be used in my own little pruvate programs, is it overkill to implement proper oop design practices?

It really depends on what you're building and why. If I was trying to build something larger, or something as a part of a learning exercise, then I would. If I was trying spike an idea or build something disposable, then I wouldn't bother.

Fire Dog writes...

Sometimes cutting corners is a good thing. Sometimes quick and dirty really is what is called for. It can be painful when something quick and dirty tries to become something it was never intended to be.

Sure, but you shouldn't learn how to cut corners until you understand why you should or shouldn't be cutting corners.

Benny Lava writes...

I don't agree with your lecturer. He is right only to a degree: a person is more likely to lean on habitual behaviour but it is far from a guaranteed automatic reaction.

I think you're reading into his point too much. It's pretty much accepted in cognitive science that people fall into natural habits. Sure, someone who's aware of their natural short comings can proactively defend against that nature.

Essentially the point is this: If you train yourself to react a certain way, then that's how your more likely to act.