Y'all are a bunch of wankers!

programming tips

Post 'em here!
Permalink Send private email Gecko 
July 15th, 2007 4:28pm
How about q-tips? I am still working on my Costco size supply of q-tips and have plenty to share.
Permalink son of parnas 
July 15th, 2007 4:35pm
Follow code conventions.

Learn as many languages as you can.

Write your own language.

Hang out on irc, mainly freenode.

Smaller, lighter, faster is better.

Start a development blog.

Focus on one big project.

Refactor, your code sucks the first time around.
Permalink Bot Berlin 
July 15th, 2007 4:36pm
The big criteria are Coupling, and Cohesion.

There are two major kinds of parsers -- LL(x) and LR(1).
Permalink SaveTheHubble 
July 15th, 2007 4:38pm
Good stuff thanks guys.

(fuck you son)
Permalink Send private email Gecko 
July 15th, 2007 4:42pm




anytime stuff starts getting complex, ask yourself "is this worth it?"

Surprising how often the answer turns out to be "no".
Permalink $-- 
July 15th, 2007 4:43pm
KISS is a good one, and most programmers know it, but I dont understand why so few follow the practice.

Sometimes I try to ask myself, if I were to give my code to a non-technical person could he figure out what was going on and possibly maintain my code.
Permalink Bot Berlin 
July 15th, 2007 4:46pm
Get something working, then refactor.

Try the most obvious solution. 

Optimize later.
Permalink rocco 
July 15th, 2007 4:46pm
Use the style/conventions of the language, environment, or platform you are using.  Don't use a C++ coding style with Perl (or vice-versa).
Permalink Send private email Wayne 
July 15th, 2007 4:47pm
"anytime stuff starts getting complex"

Software naturally starts getting complex as more and more features and functionality are added.  It takes more time and effort to make things simple than just tack on code as needed.  You *will* end up with a big ball of mud if you don't go back and refactor.

Most companies will not give you the time to back and refactor.
Permalink Send private email Wayne 
July 15th, 2007 4:50pm
"KISS is a good one, and most programmers know it, but I dont understand why so few follow the practice."

I swear by it, yet I'm just getting to the end of a big chunk of work on a project where I realise I added about 15% of effort in stuff that was not really needed, had I thought the way it would be used through.

That's why it always bears repeating. It sounds obvious, but very very few systems are designed at maximum simplicity and elegance the first time through.
Permalink $-- 
July 15th, 2007 4:50pm
Keep a file of common idioms of the current language and system you're in.  Some of those you will cut and paste (gasp!) and some are opportunities to make a library function.
Permalink rocco 
July 15th, 2007 4:51pm
rocco's are good too.

yeah Wayne, I know. The point is in having the design that makes the complexity look simple, which takes a lot of thought. I know it rarely happens in a commercial environment.
Permalink $-- 
July 15th, 2007 4:52pm
I don't usually do the KISS thing.  I create classes/functions/methods that I think I'll need sometimes before I need that.  Sometimes that works out extremely well I end up saving myself a ton of work than if I've gone the other way.  Other times, it's just code that needs to be removed on the next refactoring.
Permalink Send private email Wayne 
July 15th, 2007 4:53pm
I know people hate it, but I kind of dig it.  In hibernate and spring you can write your business logic with one line of code:

For example to get a record and return a List of the database objects.

List list = getHibernateTemplate().find("from Customer");

That is it.  same with saving a record.

To me, that defines simple.
Permalink Bot Berlin 
July 15th, 2007 4:54pm
its similar with the perl library (DBIx::Class) I use for db layer, bot. Also, if you define relationships correctly, there are all kinds of joins and so on you don't have to worry about.
Permalink $-- 
July 15th, 2007 4:56pm
I just figured out for my program, ran into this last time I tried to make something bigger than a tiny program.

It comes back to first thing learned at DeVRY in COBOL class, decomposition diagram.  Pencil and paper, or maybe a Visio.  Write out the input and output files, all of them.  Figure out where the for-next loops are going to be and exactly where to divide up the processing into functions.

It's not even pseudocode, it's higher level, it's architecture, that seems to be a bigger stumbling block of wasted time and uncertainty, to me.  How do you cope with size, scale of program (?)
Permalink Send private email LinuxOrBust 
July 15th, 2007 5:19pm
That last tip pertains to my perl programs, BTW.  The language chosen shouldn't interfere with the logical structure of the program, I should hope.
Permalink Send private email LinuxOrBust 
July 15th, 2007 5:27pm
When working in a team, the goal should be to write code that looks like one person wrote it all.  This will give you the most consistency and easy maintenance.

This can be achieved partly through standards, partly through code reviews, but mostly through assembling a team that thinks alike.
Permalink Send private email xampl 
July 15th, 2007 6:09pm
stay current and read up about all the latest, but keep perspective and choose technologies wisely.
Permalink Send private email arg! 
July 15th, 2007 8:23pm
Don't forget to get paid.
Permalink LH 
July 15th, 2007 8:36pm
If your specs aren't any good, it doesn't matter how good you are.
Permalink LeftWingPharisee 
July 15th, 2007 9:12pm
or the clients ...

Permalink trollop 
July 16th, 2007 12:35am
... applications (some legacy apps are the walking dead).
Permalink trollop 
July 16th, 2007 12:37am
KISS doesn't necessarily mean less code (though it usually does).  Some pieces don't play well together, so don't force it. 

Good names are key for variables, objects, tables, functions, procs, etc.

You can learn from both good code and bad code.  Looking at the way others code is a great way to improve your own techniques.
Permalink Kenny 
July 16th, 2007 11:54am
I regularly (although I haven't recently) download open source code just to look at it and see how they do things.  I've found some really great techniques over the years that I've incorporated into products.
Permalink Send private email Wayne 
July 16th, 2007 1:32pm

This topic is archived. No further replies will be accepted.

Other topics: July, 2007 Other topics: July, 2007 Recent topics Recent topics