php (split)

[Jonathan]

Code should document itself whenever possible. Use descriptive (but concise!) variable and function names and structure it cleanly.

His code is none of that. Hence the call for comments. When I read the line

Code: Select all

$Player_Ladder_Name[2] += 50;

I lost all interest in trying to unravel the rest.

I was kind of avoiding discussing the code directly for that reason.

Edit: Finally, a page break for me and me alone! Adding quote...

[Tank Program]

I've always thought of comments as explaining what you're trying (possibly even succeeding) to do.

I also admit to being bad about variable names. I tend to use 't' a lot, for temporary. The problems start when there's t, t2, t3, and t4...

[epsy]

All variables are temporary, it makes no sense to call any of them "temporary". Can you give an example where you would use this naming convention?

[sinewav]

/* Without the properly commented code
* I would be completely lost
* since a lot of the code I've written
* was stolen from somewhere
* and adapted to my purposes.
*/

# Think forward, be helpful.

[Tank Program]

Most often happens I think when I'm splitting strings.

Code: Select all

$data_input = "config1 = variable1,config2 = variable2";
$t = strpos($data_input, "=");
$t2 = strpos($data_input, ",");
$key1 = substr($data_input, 0, $t - 1);
$val1 = substr($data_input, $t + 1, $t2);
$data_input = substr($data_input, $t2+1);
$t = strpos($data_input, "=");
$key1 = substr($data_input, 0, $t - 1);
$val1 = substr($data_input, $t + 1);

That's a somewhat contrived example as I don't have any actual example to hand. (And yes, I know that particular example could be done much nicer, without the need for $t or $t2.)

[chrisd]

Most often happens I think when I'm splitting strings.

Code: Select all

$data_input = "config1 = variable1,config2 = variable2";
$t = strpos($data_input, "=");
$t2 = strpos($data_input, ",");
$key1 = substr($data_input, 0, $t - 1);
$val1 = substr($data_input, $t + 1, $t2);
$data_input = substr($data_input, $t2+1);
$t = strpos($data_input, "=");
$key1 = substr($data_input, 0, $t - 1);
$val1 = substr($data_input, $t + 1);

That's a somewhat contrived example as I don't have any actual example to hand. (And yes, I know that particular example could be done much nicer, without the need for $t or $t2.)

In such a case the much more meaningful names $eqloc and $commaloc can be used. Also this is screaming for a more general key-value parsing facility.

As an alternative, at work, I made some facilities to read fields separated by certain characters. In this case I could do

Code: Select all

it = input.begin();
key1   = ReadCharDelimitedField(it, input.end(), '=');
value1 = ReadCharDelimitedField(it, input.end(), ',');
key2   = ReadCharDelimitedField(it, input.end(), '=');
value2 = ReadCharDelimitedField(it, input.end(), ',');

Yes, you noticed correctly that this routine does not mind that the final comma is not there at the end. The repetition in the statements, and also the fact that each field needs exactly one line, makes this readable at a glance. Of course this is somewhat simplified C++. In real C++ one, of course, needs to also specify the types of the variables. Also, this particular function throws an exception if it is called with an empty character range, but that is another thing that makes it very usable in practice.

[Tank Program]

If I was doing this in C I would be using sprintf with a clever while loop - reading from the end and decreasing string length by adding in \0. In C++ I'd be using just standard stream redirection with a clever loop looking for the end of the stream. Actually doing it in PHP I'd be using explode(","), foreach $pair, explode("=").

On my laptop at home today (Happy May Day!) and so I could run a grep of my code. It appears I actually use $t a lot less than I thought, at least in PHP. Maybe I use it more in crappy scripts that I don't save, where I want to be quick. $t is very easy to type. Rather annoying. I wanted to find a good example where I went overboard with it.

[LOVER$BOY]

LOL!

nelg why are you using my DIRECT php code for levelling?

Anyway I've updated the script with a better guide than the last time which I just threw the code on my wiki without thinking

Also guys, I'm not good at PHP. I just learnt some basics and started to use that to create some amazing scripts for my servers and though I should share it. If a noob like me was able to understand php quite easily, then how hard would it be for others although I have to admit due to my mother being a computer engineer, I guess I got some of her genes

Anyway I use Visual Studio 2010 Professional to code my PHP because it's easy

Anyway I've updated my RPG levelling script (that nelg just shown you) so that it is a little bit more appropriate AND that it displays stuff that will make you understand where thins are.

Please tell me if I have to be MORE detailed with the script.

BTW, no offence intended to those who don't understand PHP. I'm on the same boat as you guys. After all, this levelling script took me about a week to perfect and that just shows you how bad I am

[Tank Program]

It's a great achievement for a starting programmer. You'll get better with time.

[LOVER$BOY]

Thanks for that compliment Tank

Yes. Time will decide the matter as usual.

[nelg]

:sticktoungoutat=LOVER$BOY: Direct worked in my LAN server.
Dont even think

[nux]

I've always thought of comments as explaining what you're trying (possibly even succeeding) to do.

I also admit to being bad about variable names. I tend to use 't' a lot, for temporary. The problems start when there's t, t2, t3, and t4...

Whats wrong with 1 letter variables? I use them all the time.

Also, i read somewhere (and it made a lot of sense) so use inline comments to justify why you are doing something, such as.

if (in_array($user,$admins)) die('Dont hack us!') // User has no rights

or

unlink('./cache/aifabisnbiabsfyebfiabew') // Values changed, cache needs to be regenerated

or (and this is a speculation)

eGrid::destroy() // Round ended

[Tank Program]

I think inline comments are fine too, but I like to put them above the line as that way if you're using a RCS when you do a diff the comments are clearly separate. (Below a line is probably OK too, but less logical to my mind.)

[Jonathan]

(Below a line is probably OK too, but less logical to my mind.)

Height suggests significance. The comment acts much like a section header for the "paragraph" of code underneath. You'll also see this sort of thing in good UI design. It's why, at least on the Mac OS, dialog boxes pop up about a third down the screen instead of half. Some fascinating stuff if you've ever looked at it.

[nux]

I think inline comments are fine too, but I like to put them above the line as that way if you're using a RCS when you do a diff the comments are clearly separate. (Below a line is probably OK too, but less logical to my mind.)

There are almost no diffs in my environment, its basically just me and no version control. I did those code one liners, just for demonstrating purposes. The thing with comments on a new line on top is that it stops being one liner, how do you differentiate a comment for a single line or a block? Sure you can toss some newlines at it, but something you need those newlines for something else.