The Cache: Technology Expert's Forum
 
*
Welcome, Guest. Please login or register. October 16, 2019, 06:08:49 PM

Login with username, password and session length


Pages: [1] 2
  Print  
Author Topic: Characteristics of good program/script  (Read 9158 times)
kurdt
Lifer
*****
Offline Offline

Posts: 1153


paha arkkitehti


View Profile
« on: September 04, 2009, 08:44:39 AM »

I have been reading about PHP frameworks like CodeIgniter and a lot of them try to improve how we code. I think Ruby on Rails was kinda built on this principle since they have a lot of preset stuff to help you to code better. Anyway when I was reading about CodeIgniter's documentation I started that thinking that what a good problem/script needs to have in order it to be reliable and well planned program.

Here are my thoughts:
- Error handling: I bet my scripts could be improved A LOT by doing proper error handling. It would probably also make the code better because I could debug it faster when or if it breaks.
- Controller & view: Like CodeIgnitor guys have understood correctly, model in MVC equation shouldn't be mandatory if program doesn't benefit from it. Anyway this is basic "separate the template from the script itself" approach and my opinion only way to code programs that are planned to be used for a long time and the code development will continue after initial release.
- Minimal dependencies in the code: Program should start without loading any unnecessary class or function for the first step. Then based on usage it should load libraries. This way at least the program will start as light as possible.
- Start the end goal in mind: If the program is huge (many, many features) but you probably want to get something done quickly, you should start designing the end goal in mind but make it modular so that you can built the basic functions fast, get in the customer feedback loop and then build more. You can be your own customer or in case you sell your shit, then it's "the real customer".
- Make your code "outsource-ready": Code & comment so you can separate your code so you can share only the needed code with the outsourced help. If you design your code structure right, you can get everything done much faster, cheaper and with less security risk.

Also I just happened to read Arstechnica's article about Snow Leopard (http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/) and it really gave some good insights about making operating system that basically controls your computer efficiently. I think many PHP programmers can learn a lot how to do evermore capable programs for the web by learning how leading operating systems are designed.

I'm interested to hear if Perk could share some of his thoughts because I remember he said something about planning his programs pre-coding on the paper or something like that Smiley vsloathe's is also very much requested because this is a bat country
Logged

I met god and he had nothing to say to me.
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #1 on: September 04, 2009, 09:58:42 AM »

Ruby does not enforce better coding per se. It was more intended to make coding easier and faster.
Twitter for example was banged out in a few hours originally if I remember correctly.
So in the end, there is less code that you create, which I guess leads to less opportunity for you to muck it up. lol


But to speak to your specific points.

error handling. The bane of all programmers. There is 1 rule, EVERYTHING CAN USE AN ERROR HANDLER. That said, not everything should have one., otherwise your code will be 50% error handling.
The best way to ensure you do it, is to write a class that you instantiate at the top of every page so its available to you always. And try to simplify it so you actually use it.

Agree 100% about separating code from display, though not always necessary obviously. I still am not sure I am fully into the MVC methodology, but instead tend towards a code/display methodology (i think perk does as well, though we both have our own crazy fuck methods lol). I think MVC is probably better for long term management, so thats why I am trying to head there.

minimal dependences. agree totally. Though pretty much any framework worth its salt is not going to do a NEW *.

End goal in mind. Sure, if that fits your mindset.
The spectrum of development methods can be said to be Adaptive at one end, and Predictive at the other. There are 500 different names for all the types in between, and a billion arguments why one it better than the other. To those who argue, I say Eat My Ass.
The fact is that that spectrum exists because of different circumstances.
If you do a project for NASA for example, you had better be a fucking mind-reading future telling guru. They, until runtime, are VERY predictive.
If you do a project for Joe, who wants a website to sell stuff on, don't even bother to plan ahead, just start charging money and barrel forward, checking to make sure you are on the right path as you go.
I myself, and VERY much Feature Driven Development (FDD) and probably would be called a "cowboy coder" since I tend to do what I feel is right, not what someone else said is right for some generic reason. Often I am involved in a Big Design Up Front (BDUF)  or a Design Driven Development (D3) project that usually ends up degrading into FDD anyway.
This page is pretty much THE list: http://en.wikipedia.org/wiki/List_of_software_development_philosophies

Outsource ready.
I code first, then comment.
This forces me to pay attention to what I am doing. Then it forces me to do a final run through, making sure that I am not missing or over-did anything. Structurally, I go for fast and good and verbose. I use NO shortcuts like $a == $ : true ? false; or whatever the hell it is. I indent like a mofo. I put my phone number and email on every page. I put why I did something that looks insane. I NEVER use stupid var names, always descriptive. You know how many times I work on other peoples code and see vars like $eatspussy, $shitface, $ihatemyjob. Though, best function name ever was: LoginCookierapeShowboringshitFuckuptheiraccount
or something like that.

code on paper. not quite. BUT, definitely model, plan, and see the big picture on paper.
I do database schemas on paper.
I also do rough page layouts.
List known features.
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
isthisthingon
Global Moderator
Lifer
*****
Offline Offline

Posts: 2879



View Profile
« Reply #2 on: September 04, 2009, 02:45:23 PM »

I think your points are well considered and good, along with the nuts additions, so I'll take offer my thoughts on each as well.

nb: Ruby does not enforce better coding per se. It was more intended to make coding easier and faster.

This is true, however, from only a high-level understanding of both, compared to PHP it's more structured and causes coders to follow paths that are desirable.  But old school programmers (like Perk) would prefer their own brand of "correct" coding.  Therefore, PPHP (perk's PHP) covers these things with his imposed structure but average or brilliant and undisciplined programmers would be better with Ruby IMO.

nb: error handling... The best way to ensure you do it, is to write a class that you instantiate at the top of every page so its available to you always. And try to simplify it so you actually use it.

EXACTLY.  Here's a modified snippet of how I do the exact same thing, in every class I write: (in Apex)

Code:
public Class ClassName
{
   // Exception handling
   public LHQExceptionHandler exceptionH {get; private set;} // Used to store exception
...
(now initialize in the constructor)
      exceptionH = new LHQExceptionHandler(); // I keep it live in memory at all times.
...

Then Try/Catch everything and determine what was thrown in a central exception class, not in every function:

Code:
Try
{
   ... code ...
}
Catch(Exception e)
{
   exceptionH.AddException(e);  // e can be anything including custom exceptions
}

MVC: agreed it should not be mandatory and causes some extra boilerplate code like getters and setters.  But I'm a big fan of it and think it's a great division of labor especially for teams and larger projects.  Also SaaS can't live without it.

Minimal dependencies: absolutely.  This is one of the nice things about SaaS environments, the libraries are always available, cached and fast.  But I believe it was Delphi that started a nice trend with intelligent library inclusion that others now follow (.NET, Java).  C/C++ style includes are a terrible thing to manage IMO.

End Goal in Mind: Having the "end goal in mind" seems to contradict your otherwise RAD approach to development.  RAD is great for flexibility and is the late bloomer compared to waterfall.  Agile, extreme, iterative, etc. had to prove themselves before the lemmings that fatefully followed the accepted military inspired approach changed their ways.  Gantt charts, feature freezing before line #1, ISOblahblahthousand, your basic NASA approach as nuts mentioned.  Great for NASA, shit sandwich on rye for nimble domains.

"outsource-ready": Good to strive for but overkill in some cases and mandatory in others (MVC is too, but it makes things clean and manageable).  This practice also makes your code "CruiseControl" ready (the concept, not necessarily the product).  A good thing to follow but somewhat situationally IMO.

pre-coding on paper: You can't beat paper with a stick Smiley I'm a white board chicken-scratch and erase then stare at the alphabet soup for 2 hours kind of designer.  Then I stare at it in my sleep.  For me this practice saves me SO much time and saves me from rewrites and bad design choices.  But whatever medium works for you, forcing yourself to NOT code and ONLY cogitate the architecture is key.  The bigger the application and especially in very large and complex SOA environments where distributed services comprise a total solution, for me it's a requirement.  But balls to those who don't need this "crutch" Wink  The only ones I've met produce brittle, unmanageable rewrite candidate crap - before leaving to another company to do it all over again.

I would add to your list strong typing, even in loosely typed environments (Ruby, PHP, Basic, etc.)  Perk understands this very well and does a great job of ensuring his code behaves in harmony with how it looks.  This discipline is very good to adopt and is just as important as what nb mentioned about exception handling.

Hope this was helpful.

Logged

I would love to change the world, but they won't give me the source code.
DangerMouse
Expert
****
Offline Offline

Posts: 244



View Profile
« Reply #3 on: September 04, 2009, 03:46:33 PM »

My favourites are "code to an interface not an implementation" and favour composition over inherritance. Plus couldnt agree more with the comments above.

DM

Logged
isthisthingon
Global Moderator
Lifer
*****
Offline Offline

Posts: 2879



View Profile
« Reply #4 on: September 04, 2009, 04:59:39 PM »

code to an interface not an implementation - nice one.

Favor composition over inheritance Smiley  Another keeper. 
Logged

I would love to change the world, but they won't give me the source code.
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #5 on: September 04, 2009, 05:06:10 PM »

I'm out on a fishing expedition in Grand Isle, LA, so I'm not going to be able to be as verbose as I'd like ... but I'd like to weigh in. I am not a framework guy. Well, I'm not typically OTHER people's framework guy. So I don't know if I'm the right guy to comment, because I'm typically off doing it my own way. That's why I didn't comment much on the CI thread either ... it's not that I think it's wrong or bad or anything, I'm just kind of the wrong guy to ask. But that said, I can address your questions from my own particular ... er, um... (idiom sire) IDIOM! Yes that's it!

I have been reading about PHP frameworks like CodeIgniter and a lot of them try to improve how we code. I think Ruby on Rails was kinda built on this principle since they have a lot of preset stuff to help you to code better. Anyway when I was reading about CodeIgniter's documentation I started that thinking that what a good problem/script needs to have in order it to be reliable and well planned program.
Agree with everyone above, and I'd go one step further: no programming language, or syntax, will make your program better. A crappy way of thinking, or enforced antidiscipline can make ANY language look and work like hell. which leads to my personal corollary: I should have the discipline and follow through to make any language pretty and readable.

All that said, I do agree that certain constructs are better tuned to take advantage of different ways of thinking. IT just so happens that OO really, really works for me. But even now, the old truism that "the third time you write it you will get it right" still pertains.


- Error handling: I bet my scripts could be improved A LOT by doing proper error handling. It would probably also make the code better because I could debug it faster when or if it breaks.
I think that try/catch/throw etc have made some programmers very lazy, and has just given them another syntax to express their horrible programming style. Worse, because try/catch can instantly and un-obviously completely dick with program flow and control, it is sometimes very hard to see WTF just happened. I use error handling only when I think that there's a potential problem outside of my control ie., when I'm interacting with merchant processing, or weird hardware and such. If the problem is that I MIGHT accidentally divide by zero then I should have thought it through, not wrapped my laziness in an exception framework. Try/Catch (Except) is the Ketchup of the programmers world IMO.


- Controller & view: Like CodeIgnitor guys have understood correctly, model in MVC equation shouldn't be mandatory if program doesn't benefit from it. Anyway this is basic "separate the template from the script itself" approach and my opinion only way to code programs that are planned to be used for a long time and the code development will continue after initial release.
I like design patterns. I think they provide a way for some programmers to leap past a lot of time many of us had to take to create a similar control structure from scratch. In that way, they are excellent. Adherence to them in a dogmatic way is as bad as saying "But I REALLY BELIEVE in the Buddha." For my purposes, patterns were a fun chapter in several books I've read that concisely wrap notions around code we've been doing (or trying to do) for more than 3 decades.


- Minimal dependencies in the code: Program should start without loading any unnecessary class or function for the first step. Then based on usage it should load libraries. This way at least the program will start as light as possible.
Absolutely 100% agree. and here, PHP has been a really cool change of pace for me. My previous personal framework was about 200K lines of Object Pascal (Delphi converted to Kylix). to say it was a monolithic chunk of horsepoop would be accurate. Wonderfully OO, still in production to this day and damn fast for what it was, it still is horrible to me now. I really like that, in PHP, and especially with the benefit of the APC, I can load only exactly what is necessary and keep the run time app (the page producer) absolutely as light and small as possible. Wonderful.


- Start the end goal in mind: If the program is huge (many, many features) but you probably want to get something done quickly, you should start designing the end goal in mind but make it modular so that you can built the basic functions fast, get in the customer feedback loop and then build more. You can be your own customer or in case you sell your shit, then it's "the real customer".
IMO, the bigger the job, the less likely it will be completed. And people often SAY they want something modular, but do not know how to implement that or do a good job. That was the original promise of OO and what Ruby supposedly "makes you do better." But again, if you think it through correctly, the language is just one of the tools (or hinderances LOL) to getting the job done. The way I work is to componentize rather than modularize - I'll take big jobs and divide them into little easily eaten chunks, notions, jobs or objectives - then see how I can write fundamental tools and components that will be used by all of them. This usually leads to a database structure that then gets several refactorings, and then into classes/functions/stored procedures that would be useful in handling all the top-level jobs ie., the actual goals of the project. My projects have a tendency to have "no face" for a long time as I program the fundamentals, then start to come together really quickly as I use the tools like tinker toys to accomplish the ultimate objectives. This is contrary thinking to many of the so-called RAD programming devices, where you can see results really quickly - but does not necessarily mean that the underpinnings are well designed and structured as components.

- Make your code "outsource-ready": Code & comment so you can separate your code so you can share only the needed code with the outsourced help. If you design your code structure right, you can get everything done much faster, cheaper and with less security risk.
I actually comment as I code, or sometimes even before believe it or not. I'll write: "Here's what I am going to do." Writing the storyboard for the code as a comment before I even write it. Then I'll often divide up and restructure the comments as I go, as necessary. Although it is a total cliche, I do believe that the best written software is like a novel and should be readable without commenting. There's the school of variable naming that says the name should contain the type and such - I suppose that 's OK - but I am more likely do use variable names to complete the sentence:

while ($imNotDone) or while ($keepGoing)

... to my rather esoteric way of thinking, variables can be used to complete the story that the story that the language authors were trying to write Smiley

Hope that's what you were looking for. I've managed to down 2 rum & cokes while writing this and have no idea if it actually amounted to anything  ROFLMAO
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
isthisthingon
Global Moderator
Lifer
*****
Offline Offline

Posts: 2879



View Profile
« Reply #6 on: September 04, 2009, 07:45:50 PM »

Quote
Try/Catch (Except) is the Ketchup of the programmers world

No sir  ROFLMAO  With the same discipline you refer to that allows the "knower" to rely on a single, organic and potentially Rum addled brain to anticipate every potential exception, including Try/Catch to the mix is not only not ketchup, it's the bow on a nicely wrapped gift.  Venture capitalists certainly concur.  Factoring in the range of coders from beginner to expert, having certain imposed structures like strict typing makes for perfect training wheels IMO.

This is a great thread that has lots of good tips Smiley
Logged

I would love to change the world, but they won't give me the source code.
kurdt
Lifer
*****
Offline Offline

Posts: 1153


paha arkkitehti


View Profile
« Reply #7 on: September 04, 2009, 11:09:21 PM »

I agree with most of what you guys just said. However I want to make it clear that my "start end in mind" was meant for big and continuous projects only. Usually with "average Joe projects" end isn't that far away so it's just matter of start doing stuff instead of rigorous planning.

Now that I read perkiset's reply about error handling I realized I actually do it pretty much just like perk recommends. I usually only write error handling for external data sources. With wasted CPU & bandwidth I meant for example that now my Google scraper knows that certain IP is banned but it doesn't know how to jump to next word yet. If your proxy gets captched with Google and you are scraping in page 2 with 100 results and continue to page 3 with new proxy, it will get captched immediately. This is because I made a stupid mistake in my scraper queue system so it's a little bit more difficult to skip a extension word than i++.

I think many people are not really familiar why modular is good and when it should be used. I once worked with these CMS guys who tried to make everything modular. That caused a problem that there were A LOT of modules. I think modules should consist similar functions and maybe other related functions. They should be BIG additions that add a completely new features/tools in the software. So if your program does 2 things, I think it's just better to code them all there and don't worry about being modular...

I like to see my approach more than RAD. I have seen RAD go horribly wrong when people want to be so damn agile and not realizing that there's just some aspects in software development you can't dismiss without having hard & expensive problems in the future. I think the problem is that when you work with the stuff I work with, RAD can really fuck you up in the long run. The problem is not RAD but it's the mindset it forces you in. RAD creates a lot of stress if you don't know EXACTLY how long it will take to code feature X. I like to think my approach with letters WWSD. It stands for What Would Steve Do. Basically what I do is to approach the whole application with mindset "how I can make this as cool as possible, as fast as possible and make it so it's 100% reliable". That gives me all the guidelines I need, all other philosophies are unimportant. I always start with features that matter the most for the user. The rest can come later. And the goal is to create the code really, really fast but make it so it looks like it was planned for years. I think CodeIgniter will help me tremendously with the code structure.

Of course WWSD improves all the time and it's currently sucking good principles from BDD.
« Last Edit: September 04, 2009, 11:11:46 PM by kurdt » Logged

I met god and he had nothing to say to me.
isthisthingon
Global Moderator
Lifer
*****
Offline Offline

Posts: 2879



View Profile
« Reply #8 on: September 05, 2009, 03:18:08 PM »

Quote
I started that thinking that what a good problem/script needs to have in order it to be reliable and well planned program.

>WWSD

In the end it's all about what works for you.  "Best practices" are heavily dependent on the environment.  For example, Id say for the majority of Perk's programming life he's been solo and it's been the exact opposite for me, having to deal with small to large teams on various sized projects.  Not sure about nutballs in this light but I understand he's also been doing this stuff for a very long time.  But all the experience in the world can't possibly replace you doing what's best for you and your environment. 

Side note; Perk began teaching me how to program back when I was in 5'th grade and I continue to learn from him to this day.  I believe he also taught vsloathe PHP and has offered to do the same for me.  As I'm sure you know, his Cache has quite a few extremely valuable voices on many subjects but regardless of opinions and banter he's the one I'd listen to too.

WWSD Smiley
Logged

I would love to change the world, but they won't give me the source code.
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #9 on: September 05, 2009, 03:40:25 PM »

the main takeaway from this is that we all do things the way that fits our environment.

Also regarding Code to Interface. Thats FDD, just pushing the user flow, methodology and featureset to the UI guys.
My actual project flow is:
paper flowchart
paper DB schema
wireframe mockup (i use Axure Pro)
DB implement
Determine best place to start, IE, the keystone page.
begin iterative code, test, refine, move to next feature type of cycle.

then shuffle that as needed per your idiot client (who might be yourself...)
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
isthisthingon
Global Moderator
Lifer
*****
Offline Offline

Posts: 2879



View Profile
« Reply #10 on: September 05, 2009, 03:56:23 PM »

One more thought on error handling.  Re-reading perks response I realized what I didn't mention about how I personally implement try/catch because having them everywhere - especially during initial development stages - can certainly obscure what's happening, mess with the the flow, etc. 

But having an exception handler class that you boilerplate atop all other classes and then simply switch your try/catch blocks on and off as needed is what I do in practice and what I believe qualifies as a very good habit to adopt.  Also I'm very OO in approach and depending on inheritance depth I rely heavily on switching try/catch blocks off since I need to know which layer is catching potential errors, among many other things.  Multiple errors can be rather messy as well.

nb: Thats FDD, just pushing the user flow, methodology and featureset to the UI guys.

I could be off on this but whenever I think of an interface I first assume it refers to the connecting point between modules, classes, methods, etc.  But if it actually means "develop your software as it directly pertains to the UI" I disagree.  The UI should be an interchangeable and quickly modifiable series of presentation layers, but not the driving force of the other tiers IMO.
Logged

I would love to change the world, but they won't give me the source code.
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #11 on: September 05, 2009, 04:22:28 PM »

lol youre prolly right.

I am in marketing and design, and always have been other that a short stint in Viagra peddling.

So code to interface means, the UI. hehe.
never even occurred to me to mean the interfaces between stuff.
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
isthisthingon
Global Moderator
Lifer
*****
Offline Offline

Posts: 2879



View Profile
« Reply #12 on: September 05, 2009, 05:09:57 PM »

Quote
short stint in Viagra peddling

 ROFLMAO
Logged

I would love to change the world, but they won't give me the source code.
lamontagne
Journeyman
***
Offline Offline

Posts: 89


View Profile
« Reply #13 on: September 05, 2009, 10:41:33 PM »

A good program/script manages memory very well and uses as little of it as possible at all times. I would say that is the most important characteristic of a good program in my opinion. I don't care if the code looks like a spaghetti train wreck. If it uses very little memory it's still better in my book than anything bloated. And chances are if you have memory in mind the code won't look like a spaghetti train wreck, chances are it will turn out very elegant.

Write the program, refine it to use less memory, continue to find ways to refine it. Most of the time it will require major structure changes but it will be worth it. If you do this a program will naturally work its way into being object oriented and separating itself from the interface.

Edit: When I say this of course I mean do so without killing the overall goal of the script or speed of it. What I mean here by an example is: If your program is supposed to do 140 asynchronous connections, don't decide an easy way to lower memory usage would be to use a single connection. Instead find ways to lower the memory usage while still doing 140 connections at once...
« Last Edit: September 05, 2009, 10:47:37 PM by lamontagne » Logged

"Long time no see. I only pray the caliber of your questions has improved." - Kevin Smith
isthisthingon
Global Moderator
Lifer
*****
Offline Offline

Posts: 2879



View Profile
« Reply #14 on: September 06, 2009, 02:21:39 AM »

Memory consumption being equal, I find it hard to completely dismiss all other approaches to software development.  True, an inexcusable memory hog trumps many things.  But comparable and appropriate memory management being handled, I think dismissing the "remaining" important factors of good software development as insignificant is overkill at best and an inexperienced opinion at worst
« Last Edit: September 06, 2009, 03:23:03 AM by isthisthingon » Logged

I would love to change the world, but they won't give me the source code.
Pages: [1] 2
  Print  
 
Jump to:  

Perkiset's Place Home   Best of The Cache   phpMyIDE: MySQL Stored Procedures, Functions & Triggers
Politics @ Perkiset's   Pinkhat's Perspective   
cache
mart
coder
programmers
ajax
php
javascript
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks


Valid XHTML 1.0! Valid CSS!