Any Tips On Writing More Efficient Code?

[Albatross]

Ah, but remember, Disch. Through the path of evil comes power. The inevitable fall only happens in books.

-Albatross
Self-identified Evil Programmer

[BHX]

Disch wrote:

Something difficult to use is more prone to error than an alternative that is easier to use... therefore the more difficult thing is evil.

Human error is always a factor but the easier something is to use, the less chance there is for human error.

Hmm...nope not buying it. Something difficult to use is only more prone to error for those who don't read the rules or instructions on how to use them. If something is designed with six things you have to do in order before using it or else it breaks when you try to use it. That isn't prone to error, that is human error for not understanding the order you had to turn the safety levers off before using it. Same with languages, a beginner may mess them up, but that is because they will rush into using them without fully understanding them. Where as a experienced person, when confronted with the error, will go back and read how they are supposed to be used.

If you take the easier way out, you will still have to learn the hard way eventually anyways because not all companies use the most recent standard (as dumb as that sounds). I remember talking to the Riley Hospital's HR about a programming position because I knew Unix and C/C++to help maintain their medical billing and insurance software, the gentleman I spoke to said that they still used the C++98 standard (bear in mind this is after I asked if he knew what standard they used and he pulled up the requirements on his computer), that was about two years ago when I finished college.

[EDIT] Typos

[cire]

BHXSpecter wrote:

Hmm...nope not buying it. Something difficult to use is only more prone to error for those

If anything is ever "more prone to error" then it is "more prone to error."

[Disch]

BHXSpecter wrote:

If something is designed with six things you have to do in order before using it or else it breaks when you try to use it. That isn't prone to error, that is human error for not understanding the order you had to turn the safety levers off before using it.

I could not disagree with you more.

Quite frankly I'm not even sure I understand how you could possibly disagree with what I said regarding the connection between difficulty and probability for human error. It's a very clear correlation to me: More difficult things are less likely to be accomplished successfully.

If the user makes a mistake... yes it's the user's fault. I'm not saying programmers don't need to know what they're doing. What I'm saying is a properly written lib will reduce the probability of human error.



This is the entire concept behind encapsulation. The inner workings of complex functionality remain hidden and inaccessible to the user. Instead... a simplified interface is given to the user.

Wouldn't the lib be more powerful if all the functionality was exposed and the user could manipulate it as they wanted? Of course it would... but that's a bad idea because it greatly increases the risk of misuse / user error.


Take a look at any established C/C++/Java/C#/<insert language here> library to see examples of this in action. They all encapsulate complex functionality on some level.

If you take the easier way out, you will still have to learn the hard way eventually

Again I'm not claiming the programmer shouldn't have to know what he's doing.

But if he's given the option of doing something the easy way vs. the hard way... he'd be a fool to do it the hard way (unless there were very compelling reasons why he couldn't). (EDIT: or unless it's academic /EDIT)



A lot of programming is debugging. Companies spend millions and millions of dollars every year trying to fix human error. Any techniques/approaches that can be employed to reduce the frequency/risk of programmer error is to be embraced.

[BHX]

Disch wrote:

But if he's given the option of doing something the easy way vs. the hard way... he'd be a fool to do it the hard way (unless there were very compelling reasons why he couldn't). (EDIT: or unless it's academic /EDIT)

Then I'm a fool. With that, I'm going to remove myself from this topic. It is obvious my point of view on arrays is of no use here due to me not seeing them as error prone. Fool is also getting to close to name calling and I've had my fill of criticism from others about myself this week.

[Albatross]

This is the entire concept behind encapsulation. The inner workings of complex functionality remain hidden and inaccessible to the user. Instead... a simplified interface is given to the user. Wouldn't the lib be more powerful if all the functionality was exposed and the user could manipulate it as they wanted? Of course it would... but that's a bad idea because it greatly increases the risk of misuse / user error.

You and the Java language could make a lovely couple, Disch.

I personally think that a good library should give the user a choice to expose complex inner functionality or use a simpler interface. The programmer is free to take either choice, and would choose the simpler interface in cases where they want to make their lives easier, and the more complex one if they wanted more power. >_>

-Albatross

[rapidcoder]

I personally think that a good library should give the user a choice to expose complex inner functionality or use a simpler interface.

This looks good only on paper. And reality is that libraries using this approach turn into an uncomprehensible mess very quickly. Once you expose inner workings of your library, you cannot change them without breaking customer's code - if something is exposed, they *will* use it, regardless of how many times you tell them not to. And then the customers will want to kill you if things that were working suddenly stop working, because you changed the internal things.

Actually we've got this problem with one of our products now. We provide the functionality by integrating modules X + Y + Z. The documented funcitonality works as desired, but there is a huge amount of undocumented and accidental functionality that came with those internal modules and we couldn't hide that enough well. Guess what? People *are* complaining about those internal undocumented features - I mean, they rely on them, and then they are annoyed when we change something that breaks their code.

IMHO the main purpose of encapsulation is not to protect your code against the outer-world, but to protect the outer-world from your inner code... :D
Also giving too much choice is almost always the wrong thing (especially for the people who will be supporting your code). If you think about adding features, you should be thinking twice harder which features *not to add/expose*.

Something difficult to use is only more prone to error for those who don't read the rules or instructions on how to use them

The problem is, even if the user of your code makes an error, *you* (programmer) will pay for it, too. Your product will be considered "hard to use" and won't sell / won't be popular and the customer support team will knock at your door every 5 minutes with questions.

[Disch]

@ BHXSpecter: Sorry if I offended you. It was not my intent. I need to remember to choose my wording more carefully.

Albatross wrote:

You and the Java language could make a lovely couple, Disch.

It's not just Java. C++ does it too.

Take a look at anything in STL. None of it exposes internal data. You have a relatively small subset of functions that you have to call to interact with the class. C++ even adds keywords (protected, private) whose sole purpose is to hide/protect internal functionality from user access.


Even C does it. Take a look at cstdio and FILE. FILE is a struct, but you don't ever access any of its members. Everything has to go through a simplified interface of a handful of functions.

[Albatross]

It's not just Java. C++ does it too.

I never implied that Java was the only language that did it. I just couldn't help but notice that Java's ideologies of "make programing as easy as possible" line up quite a bit with yours.

-Albatross

[Disch]

I don't think it's a Java ideology as much as it's an OOP ideology.

I'm a big fan of OOP.

[N36fSL3A]

I like to too, but some people go way too hard with it. They'll use it for everything, and their code looks like a mess.

[Disch]

Yeah... There's no denying that it can be poorly done.