i having been programming for 10+ years now, so I always try to adhere to good programming practices (variable naming, spacing, etc). Yet, almost every snippet of code for JS or PHP that you can pull up goes against those practices.

even when writing JS or PHP, where var type isn't nearly as strict as, say, Java, I'll write:

objDiv = document.getElementById( "thediv" );

or

$strName = $objUser->name();

but even examples on sun.com or php.net look like

o = document.getElementById("thediv");

or

$name = $user->name();

I understand they're both scripting languages, but I don't feel that is any reason to deviate from good programming practices.

Anyone else feel this way still, or has the whole world gone insane and I'm just wasting precious keystrokes?

tgreer commented: good thread +6

Recommended Answers

All 35 Replies

it annoys me how some same code has some named like varBstr

i make my own coding paractises. Indenting annyoys me apart from when using IF / Case statements so i just leave a line

e.g my style of html

<html>

<head>
<title> "hello" </title>
</head>

<body>

<hr>

<?php
(Some PHP Code)
?>

</body>

</html>

commented: gah - learn to spell, use code tags! -1

do you/have you programmed in languages like c/java/etc, or mostly just scripting languages?

and agreed, indenting html is a pain. i don't indent all of my tags, but i do for the majority, trying to figure out where something is nested is a pain/waste of time when dealing with huge projects

OK, I have been programming for near 30 years. I have touched every major programming language in those 30 years. Actually it is 27 years but near enough to 30 for this discussion...

Good coding practices are not written in stone, they have evolved over the years, changing as frequently as the programming langauges...

The fact is, what you consider "good" is considered "bad" by some people... as to whether you are wasting keystrokes, the question must be answered with a question, "do you work mostly solo or mostly in a team?" In a team, it is important to have a common programming style so that everyone can easily adapt to code snippets written be others in the team... When working alone, YES you are wasting keystrokes... unless you can't remember that "name" should be a string and not an int or a boolean...

I am not trying to berate you or your complaint, I have MANY issues online code samples...people are too lazy to do them right in many ways, but I think it is too general to say your way is "good" or "right" and someone else's is "bad" or "wrong"...


I suggest you learnto be more flexible, and just understand that one size does not fit all...

Incidentally, I hate touching html code that is not properly indented... but I ain't get steamed up at you guys ;-)

By the way, there is a valid argument in html code to loose the indents.... each return, space, tab, etc. is added bytes to send over the network... but to take that to the extreme, we would have an entire html page as one long line of text without any supurfluous characters...

In a team, it is important to have a common programming style so that everyone can easily adapt to code snippets written be others in the team...

my position is coming from a programmers mindset, but, more importantly, an open source mindset. i always try to make code modular, and so, with that, it has to be readable. even with js i'll stick to the same naming conventions as i do in java/etc, so that I (or someone else) knows the arg for a function is an string/int/whatever just by looking at the name.

I suggest you learnto be more flexible, and just understand that one size does not fit all...

it just confuses me that these simple principles are discarded even with languages like php, and php is a very complex scripting language.

Incidentally, I hate touching html code that is not properly indented... but I ain't get steamed up at you guys ;-)

i feel there comes a point where html indenting is borderline insane. working in a table cell nested in a table (plus some php in there) and you're looking at 8+ tabs. I try to tab to the point that you can determine the layout by looking at it. right now i am going through 1000s of lines of code that look like:

<html><head><title><? somePHP( $a ); ?></title></head>
<table attr=aleigjasie><tr><td>something</td><td>more something</td><td><? echo someMorePHP(); ?></td></tr></table></body></html>

... i am going insane ..

By the way, there is a valid argument in html code to loose the indents.... each return, space, tab, etc. is added bytes to send over the network...

i'd hate to work for the manager that enforced a no whitespace rule to save on bandwidth

i'd hate to work for the manager that enforced a no whitespace rule to save on bandwidth

I'd still indent all my code and include as much whitespace as I could. Then I'd have the server buffer HTTP output and remove all indents and whitespace. The manager will never know.. :cheesy:

I've used mostly PHP and JavaScript (4 years) which are not strict with their variable types.

I think the focus should be more on keeping your variable scope within a range where you can keep track of variable types? It tends to force you to be more OOP I think..
If you're the only one looking at the code, you can have a very wide scope and not care, but when someone else will work on it, it should be more modular..

Some IDE's understand the code you write better and give code hints when you put in variable types in their names - I like to use that when scripting some language I'm not familiar with... like actionscript..

One thing I've learned is that the more you obsess - the less work you actually achieve. Lol...

By the way, there is a valid argument in html code to loose the indents.... each return, space, tab, etc. is added bytes to send over the network... but to take that to the extreme, we would have an entire html page as one long line of text without any supurfluous characters...

also, in the case of js, it will stop (sane) programmers from reusing your scripts. just look at the google maps api . kudos to anyone outside of google that can follow that.

Well, looks my comments struck a few nerves. First, I want to say, that I worked on a very bandwidth sensitive project, and I wrote the code, then ran it through a filter which I made too, the filder just removed the superfluous whitespace and made the html 1 long line of code...the scripts too... but, again that was just an EXTREME example...

The problem with html indentation is NOT the indents, it the misuse of tables to control layout.

First, tables should never be used for anything other than tabular data, though I will admit there are times when a quick table to format a small area may be helpful and fast... I won't banter anyone for taking that way out... BUT since most "web developers" are really just macromedia "users" they don't really count as "developers" in my book... At least this is the situation in Japan, where I live and work...

Macromedia can be set to use tables or CSS to control layout, tables is the default... the problem with using macromedia is that it does NOT create clean code, so a developer needs to manually edit the code later... this can be rediculously time consumming... I would just rather recommend using a design tool to prototype a page or site and then doing the right way, yourself...

If people learned good coding habits, as you mention, I believe it must include design concepts as well, not just variable naming and code indentation...

I indent ALL my code, C, C++, vba, js, html, java, perl etc. I just make OOP easier to understand... things indented are "contained" within something else.... this is also a visual indication of scope, as mentioned above, and was the whole reason people started indenting in the first place...

When linear code predominated, no indentation was used, no one even thought of it... But we had line numbers to content with ....

<code>
10 ? rgtaylor rocks!
20 goto 10
</code>

Then we started to see OOP concepts, this made larger project MUCH easier, but it introduced scope, which didn't really exist in linear programing...

<code>
function rgtaylorMess(strMess){
document.write(strMess);
}

while(true){
rgtaylorMess("rgtaylor rocks! ");
}
</code>

Then as OOP matured we saw programming styles catchup to the design concepts, which were all about making the code easier to read and understand, since larger projects meant, usually, more people in a collaborative effort...

I am sure you all know and understand these concepts, but it just makes the current discuss have more meaning... thus my comments previously... If you are working alone or in small groups, you should be able to be more flexible, because not everyone codes the same way, and to suggest 1 way is right is simply arogant..

I live in Japan, where the physical similarities have led the culture, government and society in general to "act" like everyone is the same... not equal... just the same... So people with special needs, like handicap and mentally challenged are complete ignored in law and social services, etc. Schools teach to the lowest level of student ability, because to have basic, intermediate and advanced level course curriculum would mean admitting that some students are better at math, science, reading, etc. than others...

Japan, despite what people in the West generally think, has a horrible education system and the heart of the problem is their attitude that "one size fits all"... in all things...

I don't think the programming world would be a better place if we start trying to act similarly...

i having been programming for 10+ years now, so I always try to adhere to good programming practices (variable naming, spacing, etc). Yet, almost every snippet of code for JS or PHP that you can pull up goes against those practices.

even when writing JS or PHP, where var type isn't nearly as strict as, say, Java, I'll write:

objDiv = document.getElementById( "thediv" );

or

$strName = $objUser->name();

but even examples on sun.com or php.net look like

o = document.getElementById("thediv");

or

$name = $user->name();

I understand they're both scripting languages, but I don't feel that is any reason to deviate from good programming practices.

Anyone else feel this way still, or has the whole world gone insane and I'm just wasting precious keystrokes?

Do you guys think inline documentation can be a good coding practice?
Especially for PHP (other "typeless" scripting languages) as you cannot explicitly declare functions and properties of a class as private/public. And you cannot specify the datatypes of variables and function returns.

Could this be an alternative to having to name variables with type information?

Member Avatar for Rhyan

I won't banter anyone for taking that way out... BUT since most "web developers" are really just macromedia "users" they don't really count as "developers" in my book... At least this is the situation in Japan, where I live and work...

I would never ever dare opposing an expert with a 30 year of coding experience, however, maybe it is my missunderstanding, but still Macromedia products seem to be "THE PRODUCTS" for web development.

Let's just clarify - users that stick to the quick-add buttons, draw table layots and stuff are the ones you don't count, is that correct?
I have been using MM tools since Dreamweaver 3 when I took my first steps in web design. That is how I learned - in split screen, watching the code change. Now I use it the other way arround - still in dual view, writing the code and watching the changes in the preview screen :).

Now, as an MM user, I really enjoy the code assistance it provides - the auto tag closing functionallity, the code hints, the Reference it has as help, and of course - code colouring that is trully helpful in error finding. And you say the code is dirty...well...obvioursly you have never ever tried to re-code or edit a page created by MS Office products....well that is a dirty code. A page with tabular data, exported from WORD as a web page, had an output of 350Kb.!!! After automated Macromedia word clearing functions it was reduced to 60kb. After a complete cleaning, sticking to css rules and reduction of unnecessary code, at the end I got a really nice page, looking the same way as in word, still - only 20Kb TOTAL. Well that is a messy code...

Now - about standards - a few years ago, when "the browser wars" raged, we all have seen the pro-ie or pro-Netscape coding. You all remember what a complete mess it was - a website saying - you have to utilize this resolution and IE preferably. Now, after the css and web standards in general are supported by more and more coders, and more and more browsers(although there are some differences), I find it much more easier and really much better to code a page. I try to stick to the standards and avoid the "hacks" in order to achieve what I want, and I do so, because the hacks won't work tomorrow. Another thing is - another guy may support this website tomorrow, so why should he reinvent or rewrite the complete code - he has just change the "skin", the bones are always the same.
It is the same way for me in php / javascript when I code. I try to make the code more clear, more user-friendly, and eventually I try to leave as many code hints and in-line comments to support myself, or the coder after me - you can never remember what the hell you were thinking 2-3 months ago when you coded a page, unless you have hints or comments...and what about the things you coded an year ago?

Indentation is readability. True that no indentation or no whitespaces saves bandwith, but, I don't think that at present and maybe in near future there will be a problem with the bandwidth - I could not imagine a download speed of 60K 2 years ago(at least not here in Bulgaria), still, today if you drop below 50k your provider sucks :). Soon we will see such speed even on mobile devices, so ... how much whitespace-saving will spare from the bandwidth?!

And at last, but not least - If you want to improve, you have to learn every day. I grasp new ideas from the other coders on the web, by reading the code of the pages I like, and I would be glad if yonger coders are able to get ideas from the pages I've done, and that is how the web will go better every day. And what makes me sad is that there are a lot of web coders that just do it for the money, regardless of the messy, full of errors, not corresponding to the standards code they produce.

Keep it pure I would say :)

Do you guys think inline documentation can be a good coding practice?
Especially for PHP (other "typeless" scripting languages) as you cannot explicitly declare functions and properties of a class as private/public. And you cannot specify the datatypes of variables and function returns.

Could this be an alternative to having to name variables with type information?

i comment as much as i can, but only in short bursts. when commenting how a function works, i might write a few lines, but otherwise, i just comment a couple words explaining the next block of code. i find it easier to read through a little well written code with a brief comment than a chunk of code with lot of commenting.

and usually, when variables are named with type/scope, i find i don't even have to look at commenting. when i see "strName", "objName", "and "gstrName", i know i am probably looking at the string for a name, maybe the sql results for a query regarding a name, and a global string for a name, respectively. seeing those vars named "name", "query", and "name", you can't tell scope or type.

my main gripe, not directed towards anyone specifically, is that these are basic programming 101 practices that you will be taught in any intro class when dicking around with VB6, or whatever. php shouldn't be any different, they are still variables, they still have a type, they still have a scope. just because php isn't strict about data types doesn't mean that coding principles should be more lax. indenting, naming, standards, these all effect readability and overall quality of code and lack thereof, in any other languages, are all signs of amateur coding.

i comment as much as i can, but only in short bursts.

ahah... same here, i think 1hour's documentation to 10 hour's coding is a reasonable ratio... it's not just laziness either; i might change something, and then I'd have to rewrite the documentation aswell as the dependancies =P

i don't like inline comments anywhere. just big explanative descriptions infront of functions or at the end of each file. i like doxygen/javadoc type tools; that make funky documentation minisites based on "super comments" in code. commenting inside functions; only ever to disable parts of the function, or to say "//\todo FIX THIS!" or similar

i would certainly never comment HTML except as a means to prevent it being displayed temporarily; i indent HTML to my own style - completely rigid nested indentation rules makes some files look like the himalayas sideways ;)

i think languages like PHP, Javascript, and to a lesser extent Perl (and others, [ including VB6 without Option Explicit]), almost encourage lax instantiation of variables, and maybe "bad programming practices"; just because they allow it to be done, if they didn't allow it, people wouldn't do it. but because the interprettor doesn't care, certain developers don't care.

in my opinion; it's even MORE important with an interpretted type-loose language to follow , at least some kind of standard. it's much easier to make stupid mistakes than with a strictly typed language.

but saying that, i take much more pride in work that i do in compiled languages than i do with work in interpretted languages.. perhaps it's because i see interpretted languages as temporary testing platforms for concepts; and that work in them will be generally harder to maintain.. or maybe i just have all that free time while compiling to tidy things up... :rolleyes:

I want to address the inline comments issue... In interpreted languages, comments = processor overhead... so use them effectively, yet don't abuse them. In compiled languages comments = compiler overhead, but that is a 1 time deal and the overall effect is only felt if you are compiling a application that takes hours to compile... Then I say, err on the side of abuse...

The more you comment you code, the easier it is for you or someone else to redress it later... Large intro comments for Javadocs or similar are fine for explaining what a class or method is for, but they don't help someone understand "how" it is doing it...

I am the CEO now, and though I insist in continuing to wrote code along with my developers, my developers are very thankful for the amount of comments I placed in the code when the company was young and I did 99% of the work myself...

I have just initiated a rewrite of PHP code I wrote 6 years ago. The developing team would have to rewrite the code completely if they didn't have my robust comments....

I am also initiating a new codign project which will use Java and JSP. The requirements for the development team will include robust commenting... I PAY them for the commenting & coding time, so I expect robust comments, there is no excuses otherwise.

Now, for the comments above about "how" one uses Macromedia and/or Word... I guess I would first say that I have had the opportunity to work with output from many editors than most people. I have used Macromedia products as well as many others, always looking for a "faster" way than hand coding... In the end, I found some good tools that work as RAD environments b ut allow me to keep the power and flexibility of hand coding...

For the guy who codes in MM's code window and views the changes in the preview window, I would say that is a fine way to do it... and you can probably get clean code... the messy code comes from letting the MM code engine do the work for you... You can always tell because you will end up with code fragments that are superfluous... for example

<span style="font-size: 18pt;"></span>
empty span tags is common...

<a href="#"></a>
empty anchor tags is common...


etc.

The important thing is that you stay in control of the code, not let the application control the code...

I want to be clear, also about naming conventions, I agree that good naming conventions are a must, especially on large or distributed projects... But there is more than 1 way to skin a cat, Why anyone would be skinning cats..I don't know... But to claim it is "mature" coding to use 1 method because it was taught in some book and/or some class in basic programming is just rediculous... VB developers adopted those techniques because they had 1) a limited selection of variable types 2) only moderate variable typing.... There are languages that FORCE specific constructs for certain variable types... Basic, which is where MS started when trying to build VB, was one... Such as String variable must begin with "$", etc. These were common... people who worked with the old languages got used to the visual representation of type, and thus when VB, etc. were more name friendly, they searched for a way to maintain that clarity...

I use iNum, sNum, isNum, hasNum, lNum, dNum, fNum, etc. which are C & C++ common naming conventions... camel case and all.... I am sure most of you looking at those have NO trouble figuring out what TYPE each of them would hold...

THUS, my comment, just because it woks for you, doesn't mean it is "right" for everyone, and just because some teacher told you this is the way I expect to see your code does not make it the way everyone should code...

My first CS teacher, back 27 years ago, told me I had to completely plan the code, even write it down before coding a single line of code... he said that this was "good" programming practice.... I NEVER did.... I found that I could code directly into the machine with better accuracy than on paper, I also had bad handwritting... and I felt that code TWICE was a waste of my precious time... I would code it, debug it, add a few bugs on purpose, print it, then fix those added bugs, and print it again... Then I would have him signoff the buggy version as draft code and sign off the fixed version as final code...

He took the app and code printouts and examined them to determine grades... I always got an "A"... I had to add the bugs because perfect draft code was very unlikely in the best of cases, and he would have realized I was NOT following instructions 100%...

The point is, "mature" programming is finding a way that works for you and being consistent... NOT following someone elses rigid ideas... If you are consistent, then you will have easier times understanding your own code months or years later, and others will get adjusted to your coding style when you work in a team, even if you don't have 100% the same styles... AND good comments, inline, make the difference when you are adjusting to the new guys...

I love the conecpt of Javadocs, BUT Javadocs can use inline comments too, if written correctly... The trouble is most developers don't give enough information in the comments, before during or after the code to make the Javadoc generated comments very useful...

I see javadocs with VERY useless information frequently...

I'd still indent all my code and include as much whitespace as I could. Then I'd have the server buffer HTTP output and remove all indents and whitespace. The manager will never know.. :cheesy:

I've used mostly PHP and JavaScript (4 years) which are not strict with their variable types.

I think the focus should be more on keeping your variable scope within a range where you can keep track of variable types? It tends to force you to be more OOP I think..
If you're the only one looking at the code, you can have a very wide scope and not care, but when someone else will work on it, it should be more modular..

Some IDE's understand the code you write better and give code hints when you put in variable types in their names - I like to use that when scripting some language I'm not familiar with... like actionscript..

One thing I've learned is that the more you obsess - the less work you actually achieve. Lol...

I absolutely agree with this.

I have worked in PHP now for several months, Java about a year, C++ a few months, and I have found that apart from the awful mess of HTML indenting (3 nested tables, and half ur working space is gaps ;x), that proper indentation, casting, variable types, indentation and uses of classes is critical to the further enhancement of software development projects.

It is critical that when software is designed, it is not designed using short sightedness of a sole programmer who's coding standard and structure is a royal mess.
As I myself having taken a PHP development position (my first actually :confused:), I have come to realisation, first of all which I already believed, that proper code flow, structure and indentation is at the outmost, critical for reusability, improvement and modification in time.
On top of that, proper documentation is vital, it cannot be said enough how important having documentation of a system is.

Modular programming practises imo, should be enforced in every teaching institution as a first programming method, and stress its importance. Each individual will develop their own methods and structures, but it is critical in team environments, and open source, that the same structure, and declarations etc. be consistent, the same throughout and properly documented/commented.

I myself am only 21, but I do know a thing or two about working in projects with other coders/developers/designers who can't design or code cleanly.

This goes back to my earlier comment that the indentation of HTML only becomes an issue when you have embedded tables, which is usually the result of tables being used for layout control....

Since "good" coding practices include not using tables for layout, then any pages, people, etc who suffer from the HTML indentation problem would indicate that someone didn't use "good" coding sytles anyway...

I am happy to hear you got a job coding PHP.... amazing for someone who has only been coding in it a short time...

very FEW professional projects have an assigned and/or documented ... convention for variable names... at least in my experience... a team that works long together may develop a standard system simply by conforming to one or anothers habits... often by conforming to the lead developer's habits...

I often find that names used in one component of an OOP large scale project may be completely different from those used on another... So they are not common throughout... but as long as they are reasonable & well commented and each person is consistent, it is not too difficult to pickup someone elses code, when they have a different style than you, read it, and understand it...

Yes that is true, it is easier to read and pickup on other coders style if they are clean and have good consistent naming convention, and at least some consistency throughout the project. My biggest annoyance so far, is the not-so-strict use of classes where they should be used, and the use of classes when they aren't needed. I find it easier to use classes not just for reuse, but also accessibility within a project, and easy enough to duplicate to other projects with minimal modification.

HTML indentation comes down to individuals preferences. I try to keep everything indented but it just becomes messy. For myself and reading code quickly and efficiently, I find that having structured and properly indented code is critical, as you can quickly scan sections to find where a problem, or modification/improvement can be achieved. I find it very difficult to scan long sections that are backed up against the wall with no flow or indentation, and all over the shop.
It may be time consuming, but I find that with properly structured code it is very easy for others to understand what you are trying to do.

But personally, I prefer the OOP approach, and I try at all times to program in the OOP methodology, and abstain from classical programming that uses inline functions, bad naming, and just including a horde of functions within a page that just are not needed at all, where classes have an advantage, and not only that, they are anonymous for data formatting.

At work, I have already cut rendering time 3 quarters down from its original on a specific page within a specific project, by using classes and low amount of includes (some of these files are includes within includes within includes, it took me an hour just to find one bloody function that didn't even do anything!). Lesson learnt - use classes.

Working with unindented and uncommented/undocumented code is a nightmare.

I think that indentation is essential; it makes reading code far easier and helps avoid simple mistakes matching stuff up.

On larger projects it doesn't matter what set of standards you stick to so long as everyone uses them and produces clean readable (and therefore maintainable) code is produced.

My rule of thumb is after every function, if its not obvious what it does at a glance or isn't a one-liner, add a quick comment saying what it does. If needs be give a quick example of use.

I use iNum, sNum, isNum, hasNum, lNum, dNum, fNum, etc. which are C & C++ common naming conventions... camel case and all.... I am sure most of you looking at those have NO trouble figuring out what TYPE each of them would hold...

I stopped using those conventions when I started using object orientated languges... iNumber, etc, works ok for numbers, strings etc, but when you're using references to custom types/classes; what's correct?

Something like objReference is always going to work; but it's as bad as just 'reference', I suppose it's always possible to abbreviate a class: vctMyVector, lstMyList etc, but it's harder when using custom types/classes that have very literal names, I have an anecdotal 'box' class for example, that draws boxes ( as a classic example ) - so all references to objects of the box type can start with the prefix box - a'la boxTheBox; but I might have another class that acts as a 'box' of variables ( maybe a 3D array ), we have boxForDrawing, boxOfVariables, or drwboxMyBox, memboxMyBox... ahh... I like not...

So, I stick with short, unprefixed names that describe the context of an object within another; memoryPool for the memory box, drawObject for the drawing box. Heck I don't like camel notation either : so it'd be memory_pool and draw_object. Then, if I change the type of a memory pool to some 8 dimensional structure, it can still be a memory_pool, if I decide circles are nicer than boxes, it can still be a draw_object. I suppose I could have made it a shpDraw and a memPool to begin with; but it's seems like an uneccessary convolution - starting to use a convention that I don't believe is going to hold out indefinately - and because of my nature, if a convention doesn't work in one circumstance, it can't be the convention anywhere. So, for that reason alone, I divorced type prefixing very shortly after we first got acquainted...

I often find that names used in one component of an OOP large scale project may be completely different from those used on another... So they are not common throughout... but as long as they are reasonable & well commented and each person is consistent, it is not too difficult to pickup someone elses code, when they have a different style than you, read it, and understand it...

This demonstrates, or perhaps at least allows me to draw attention to, one of the key principles of component programming. As long as the component works - it shouldn't matter what's going on inside it. That is, a 'component' implies a well encapsulated object or static library that provides a small - to - moderate, and very specific functionality. Public documentation for a component should be written from an external perspective, and external usages of that component should rely on exposed methods and interfaces... I suppose it's important for those methods and interfaces to follow some kind of convention; get_something( ), set_something( ), is_something( ), do_something( ) et cetera [ although the do is probably unneccessary there ].

-

On the subject of indentation... tabs or spaces ? =P I hate system tabs in program code ( because program/os one might say a tab is 2 columns, program/os 2 might say a tab is 8 columns ), but I don't mind them in XML/HTML/CSS/etc.. Perhaps that's because you can load up XML in document explorers, and they don't care about tabwidth..

Interesting that you say prefixing type doesn't hold hold up indefinitely... you have used a rather silly example, if anyone was stupid enough to call something just "box" then they deserve to have issues... Infact the previous examples given above were just another method of type prefixing... However, there is a difference between type prefixing a method name, which I don't do, and type prefixing a variable...

Class box will have some member variables which will be either other custom types or native types... type prefixing will still ALWAYS work... member functions are named for PURPOSE and should not have a type because they logically don't "store" a type they have a return type but that is very different... The variable name should also reflect purpose to some extent and prefixing it with type, which only fails if you can't think of a good type name and that is your fault not the system's fault, is a very valuable tool... you see iNumResults and you can guess, it is an Int and it stores the number of results, presumably from a SQL statement....
some people prefer intNumResults, which is just fine... I use simple prefixed for native types and longer prefixes for custom types, so when I look at boxDisplayFrame I know that it holds a "box" type, which is a custom type and it represents the "display frame"

Camel case is a matter of preference, I find it shortens names since I don't have to have the extra underscores and provides EQUAL readability... the important thing is that you are consistent, then you don't have to remember what you typed... it is second nature...

I hate working on aproject where some items are named like this: program_analysis_results_list
and others like this:
programAnalysisResultsList
then you can't remeber which way was THAT particular one written.... I spend too much time searching for them and writing them down so I don't get them messed up... and I hate wasting that time...

You are right, OOP means that the whole project doesn't need to use ONE way.... which was my WHOLE POINT... this thread began as a discussion of proper coding... and my whole point is that ther RIGHT way of coding is "whatever you feel comfortable with!" Only an seriously anal retentive sphincter would care about enforncing "their" own codign style on everyone else... ;-)

Mmm.. I didn't read your original words clearly with regard to the component internals; seems we agree. It's a point worthy of being re-iterated numerous times though; that it's more important to maintain consistency than conform to someone else's practices.

With type prefixing; the developer at some point has to make a reasoned abstraction of the variable's type description - and that abstraction has to facilitate flexibility; there's no point calling a variable iNum if it might be changed to a long-integer at definition later; and prefixing all long's as 'i' to avoid that problem is obscuring type information informally, that would pertain to lesser readability, even confusion.

That was a somewhat contrived example. In a perfect system; there wouldn't be many names of fully qualified classes sitting around in hard-coded routines; but unplanned systems often start out imperfect =P.

Heres a q about programming standards.

Should i use <?php or <?

<?php because you won't always know if the sever is using apache, and if it has short tags on.

Thanks.

I say, typically, you should use the full standard method of delcaring your PHP code sections as suggested above.
BUT, the following guidelines can help anyone who has this question:
If you plan on sharing code: use the full declaration <?php ... ?>
If you will not share and have total control over the server where it will run: do whatever you like short or long
If you will not share and you DON'T have total control over the server where it will run: use the full declaration <?php ... ?>

So following those guides, only people writing code for an internal prorietary system with full control over server environment should use short tags for declaring php code sections, ALL others should just use the full <?php declaration ;-)

Matt, I agree, the most important thing is being conisistent... cool we agree to agree, new one on me there...

About the variable naming though... This goes back to OOP, if you need to change the implementation, you only have to worry about the effected modules, and since code refactoring is a quite common function in IDEs, it is little effort to keep the prefix in line with the actual type... When I , which rarely happens, need to alter the type of a variable, I refactor the names, for example iNum would become dNum or lNum if I changed it to a double or long respectively...
Code refactoring for these rare cases takes like 3 seconds but the benefits of knowing what you are looking at, at first glance, is priceless... kinda like MasterCard...

So I guess there, we will have to agree to disagree ;-) ... sigh ... that's more like it...

But again I reiterate, I use what I find works best for me, and encourage you to use what works best for you!

Some things in this world are obvious right vs wrong, but so many people feel the need to, I don't know, justify their existance or prop-up their self image by forcing others to agree that, A) there is only 1 way and B) it is their own way that is THE one right way...

I tell these people, if you feel the need to enforce your ideas on others, you are usually wrong...
Sharing ideas, learning what other use, what works and what doesn't (and why) for others is a GREAT thing. I encourage ALL my employees to grow, learn and try new things... We set development standards and rules in our teams by concensus within the team. We make accountability a key aspect with this freedom, if something just isn't working, they are expected to recognize it, document it, and fix it BEFORE it is allowed to get out of hand...
Through this we have developed a set of "best practices" which are our own, what has/hasn't worked for us, why and why not... It helps us do the job better, faster, stronger... like Steve Austin (the 6 Million Dollar Man) not the guy from Bakersfield, California... Bionic Coders' Club ... cool name, but not one we actually use... so that is NOT an advertisment... I wonder if that exists somewhere... any I digress...

So for ALL those out there with questions about coding standards, follow these simple rules...
Be Clear
Be Concise
Be Consistent
Be Flexible
Be Open
and
Think Ahead

Most problems are easier to avoid than to fix!

Does "coding standards" include the structure of your projects file system?
Just want to know what type of file structure you guys go with or if thats not considered a part of the "coding standards".

For big PHP projects i like to make usuallt 5 dirs:

Res (pictures etc)
Lib (#include files)
Upload
Src (Pages)
Dta (Data files)

I would call a file e.g Src_Index.php

Again, I reply with use what works for you, but think it out thoroughly before you being...

A finely tuned file system is AS importantant as a well designed database schema... yet it is where people often go wrong right from the start...

The key is to have a full plan of the final project before you begin. You don't have to know every detail, but you have a firm plan about what will be included and generally how it will work... from this you can design a file system that best meets your requirements.

It is a good idea, as mentioned above to have some centralized locations for non-code files, such as images, flash files, includes, etc.... I have seen projects where they have image subdirectories, for example, in every directory where the pages need images, which is pretty much everywhere, managing these becomes a nightmare, seriously.... CENTRALIZE these sort of resources and your life will be much easier. Besides, it facilitates reuse...

Other than that, I have also worked on projects where ALL code documents were stored in 1 common directory, so there was no depth in the file structure... this had advantages and disadvantages, as does building a files structure that matches your site navigation and/or layout...

That is another option, MANY people promote building file structures that match your site navigation or system layout, or flow... etc. This sounds good at first, but it can lead to serious maintenance costs, especially when making even slight changes to site navigation or design...

I am NOT saying any of these is better or worse than the others, except to say keep the resources centralized, but I want you to understand the various options commonly used and know that it is important to plan this out, don't let yourself be led into building folders ad-hoc (as you need them) if you find this happening, you didn't plan well enough, try better next time ;-)

One other point that everyone should plan at this stage is the linkage of their contents... I mean the actual format the URLs will take... relative vs absolute URLs, etc. when one should be used, when another should be used... each has an advantage, and search engines often use this info to help rank your site...

Absolute links are better when moving the source page within your site but worse when moving the target page within your site. Relative links break either way, so they are always on the worse side... BUT if you have a complex file/folder structure you may have very long, complex absolute URLs and be tempted to swutch to relative...

One work around that I have used, is URL rewriting with mod_rewrite... You can simplify long URLs in a complex folder structure allowing you to keep those long URLs simple enough so you don't get tempted to switch to relative URLs...

Also, take advantage of PHPs enviornment variables to keep absolute URLs easy to write and flexible...

Honestly, I keep most of my code files in a limited number of folders... too few and it is hard to find the right one in a huge list, too many and you get click crazy trying to work with the code.... I try to strike a balance...

Peace,

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.