[kevin_mchugh]

At the unnamed University I attend, many of my peers seem to be under the impression that as long as piece of code/software produces the required results then its correct.

For the most part our lecturers fall into two categories, those who agree with "by any means necessary" and those who think "it runs but there is a better way".

I myself am always convinced, no matter how good something appears to be, I am missing something or their is just simply a better way to do things. Whether their is or not, I don't always know.

Take today's little project/toy for example. I wrote an Android application that would pull all the MP3 links out of a given RSS Podcast feed and queue them up in a Media Player. Now I could have done battle with my nemesis the "XML Parser" or I could just download the page and use a file stream to get out any lines which contained ".mp3", add in a bit of regular expression magic and store the URL in a linked list ready for playing.

As I was only writing this code for me, I just did the "dirty" method.

What does all this have to do with anything? Well I guess I just wondered if their really is a right way to do things? Do people even care beyond professional pride? Will you ever find a definitive solution to a problem?

Do you just make do with what you have?

And why do I get the feeling I am about to get the "real programmers write from the command line with a while walking bear foot through eight foot snow drifts."

This is just me thinking out loud.

[modi123_1]

Damn.. I didn't hit send before my meeting.. but these really hurt my eyes.

Quote

its it's correct
if their there really
walking bear bare foot

In short though - there are multiple ways to skin a cat or tackle a problem. In theory if it produces the desired results then it is right. Elegance, abstraction, minimal line number count, and fancy method use is all up to the developer and any standards he might have imposed on him (say by his company that writes his paychecks).

Even in highly structured languages like .NET two people can go at a task radically differently. Hell there's an old axiom that exists: any code you wrote, that is six months old, might as well have been written by someone else.

Personally I say there's a level of pride one should take in their code. You don't want to hand in a paper half assed why write your code that way? Make it presentable, have comments, be orderly, and be consistent. There is also a level of anal-retentive you should avoid. Go nuts enough to satisfy your itch but you'll learn that there's not enough time or caring by anyone else to go way off the reservation of sanity.

This post has been edited by modi123_1: 03 March 2011 - 01:39 PM

[macosxnerd101]

There is no right answer when programming. But there are a lot of wrong answers. Code that is so terribly inefficient that it creates bottlenecks is wrong. Using deprecated tools is wrong; they were deprecated for a reason and should no longer be used. You never know, they may no longer be there next year. I would also argue that sloppy, unmaintainable code is wrong b/c it makes it difficult for others to read and maintain it.

When determining if I am satisfied with my solution, I use the following tests:
-Does it work?
-Is it efficient?
-Are responsibilities appropriately delegated to components?
-Could someone else maintain my code, even if (*gasp*) I did not include comments?
-Is there room and time to significantly optimize the solution?

[kamisamanou]

macosxnerd101, on 03 March 2011 - 11:11 PM, said:

Using deprecated tools is wrong; they were deprecated for a reason and should no longer be used.

I wish my programming professor understood that line. He teaches us what he likes. I do the research and learn what is right.

[cfoley]

In this case, one could argue the regex solution is the better of the two since it could be more easily adapted to other formats.

[hookiethe1]

I think these questions are a sign of your development as a programmer. When I was in my very first programming class, a working program was a finished program, and as far as I know they were graded using the same criteria. I think that is fair, because it is an introductory class, the assignments are short, and despite the ugliness or inefficiency of the code, the fact that you can make it work is enough to demonstrate knowledge of the subject.As I got into higher level programming classes requirements changed, they started cracking down on things like comments and forcing us to submit documentation along with the code for assignments because it was no longer enough to write working code, it had to be decent, readable, sensible working code.
It might be partly because of that school progression, but also my own inherent professional pride, that I will not submit anything at work for peer review until I've gone over it in very fine detail, lined up all my indents, tidied up my comments, and made sure that everything flows logically and smoothly.

(this reminds me of the "cheating" thread that was around here not very long ago...)

[Shane Hudson]

macosxnerd101, on 04 March 2011 - 05:11 AM, said:

There is no right answer when programming. But there are a lot of wrong answers.

I agree with this completely. So very often I see code that works well enough, but the logic behind it (or just the code being messy) is completely twisted. Sure it works, but it's by no means a good way of programming. Now I may not be as up to date with the standards and general practice as some people, but I can tell if my code is ugly or not!

[Creecher]

kamisamanou, on 04 March 2011 - 01:33 AM, said:

macosxnerd101, on 03 March 2011 - 11:11 PM, said:

Using deprecated tools is wrong; they were deprecated for a reason and should no longer be used.

I wish my programming professor understood that line. He teaches us what he likes. I do the research and learn what is right.

This.

My Web App. Dev teacher likes to use deprecated PHP/HTML/CSS(whatever, really) scripting and then expect us to use that when we write our own projects. Though I can't say I have never used a deprecated HTML tag(or whatever) I will say I (mostly) do that out of laziness.

Though I usually have to write a bit more or use Google a little more than other people, I like to use the newer updated versions of older functions. They tend to make things easier.

[Sergio Tapia]

Always leave the camp ground cleaner than you found it.

It's an investment that will pay for itself during the long run. You might not see immediate benefits, but later on you will be thankful you cleaned up your code.

There is no 'perfect solution' - there are many ways to cook the proverbial chicken.

Ultimately you started a project to solve a problem. If your problem is solved, it's time to start refactoring until there is nothing more to take out. Small methods and small classes. Trust me, you don't want to start programming gung-ho and suddenly finding yourself in a 140 line method. I've been there and it sucks.

You carry a lot of technical debt when doing things as quickly as possible with no regards for correct engineering. You will eventually have to face it, it's your choice whether you want to face it here and now, or later on during maintenance.

This post has been edited by Sergio Tapia: 04 March 2011 - 08:59 AM

[atraub]

Quote

There is no right answer when programming

There is no single right answer when programming.

"As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble." -Ralph Waldo Emerson

This post has been edited by atraub: 04 March 2011 - 01:00 PM

[cfoley]

I think there is a sweet spot between churning out the first thing that works and engineering, optimising and refactoring (over and over) the optimum solution. The former is saving up trouble for the future, the latter means you will never meet a deadline.

[grimpirate]

The right solution is always whichever uses the least amount of clock cycles and doesn't create deadlocks or bottleneck conditions.

This post has been edited by grimpirate: 05 March 2011 - 06:44 PM

[SixOfEleven]

We, as programmers, have a responsibility to write good code that performs as expected and reliably. I'm not in the "just getting working" camp. In the camp, getting working and getting working well and reliably. I think I need to add my favorite saying to my signature again. "Just because you can do something with code doesn't mean that you should."

<rant>
That includes code that has the potential to harm somebody's computer. If you're smart enough to write malware that will damage somebody's computer, don't. Use your knowledge and create something helpful to the world.
</rant>

[JackOfAllTrades]

Wait until you get into "the real world", with impossible deadlines, an existing codebase with badly-organized procedural code and no time -- or will from the bosses -- for refactoring. You will find that often you are stuck with code that was written with a "just get it working" mentality...and once you're in that morass, Og help you.

If you can start out fresh doing the right things...please, please, please...do it correctly!

[cfoley]

grimpirate, on 06 March 2011 - 01:40 AM, said:

The right solution is always whichever uses the least amount of clock cycles and doesn't create deadlocks or bottleneck conditions.

Always?

Surely the right answer is sometimes the one that uses the least memory, or is the most maintainable, or is the most easily extensible, or is the fastest to develop, or is easiest to write test code for. Probably the best answer most of the time is a compromise between all these factors and more.