http://www.dev102.com/2008/03/18/how-to-convert-minutes-to-hours-with-php/ 

As posted by Admin. Awesome.

 One day he'll look back at this and laugh. We, on the other hand, can start now... hehehehehehe

From the comments on the site:

 

Admin:

Thanks for all the comments.
I like your ideas and i will definitely use them

 

ALL AT ONCE.

 

$Minutes = $Minutes .“0″;

so 4 minutes would become 00:40

That's the only actual bug that I see, aside from it being bloatware.   

// this should print 3:40

What you're not sure?  did you actually test your code?

You know you're in good territory when a simple mathematical function requires use of explode. 

bstorer:

You know you're in good territory when a simple mathematical function requires use of explode. 

This made my day.  I want a t-shirt with that printed on it.  You, sir, win array_sum(explode(' ', str_repeat('1000 ', 1000))) Internets!

Any time someone introduces "a code", especially "a PHP code", you know it's going to be worth reading.

belgariontheking:

That's the only actual bug that I see, aside from it being bloatware.   

 

The first comment on that post is even better for bloatware, obviously written by someone who's never ever heard of sprintf():

return str_repeat(’0′, 2 - strlen($hours)) . $hours . ‘:’ . str_repeat(’0′, 2 - strlen($minutes)) . $minutes;

I really wonder what it is about PHP posts that makes people show off how bad their coding skills are by filling the comments section with useless blather. Especially useless blather of the "reimplementing the wheel by using square rocks" type. Must be something about the "PHP is so easy, even a braindead rotten paramecium can do it!" mentality. Everyone has to show off their latest/greatest "ooooh shiny!" construction.

MarcB:

The first comment on that post is even better for bloatware, obviously written by someone who's never ever heard of sprintf():

return str_repeat(’0′, 2 - strlen($hours)) . $hours . ‘:’ . str_repeat(’0′, 2 - strlen($minutes)) . $minutes;

I really wonder what it is about PHP posts that makes people show off how bad their coding skills are by filling the comments section with useless blather. Especially useless blather of the "reimplementing the wheel by using square rocks" type. Must be something about the "PHP is so easy, even a braindead rotten paramecium can do it!" mentality. Everyone has to show off their latest/greatest "ooooh shiny!" construction.

 

Wait... so PHP == Java now?

*ducks*

MasterPlanSoftware:

MarcB:

The first comment on that post is even better for bloatware, obviously written by someone who's never ever heard of sprintf():

return str_repeat(’0′, 2 - strlen($hours)) . $hours . ‘:’ . str_repeat(’0′, 2 - strlen($minutes)) . $minutes;

I really wonder what it is about PHP posts that makes people show off how bad their coding skills are by filling the comments section with useless blather. Especially useless blather of the "reimplementing the wheel by using square rocks" type. Must be something about the "PHP is so easy, even a braindead rotten paramecium can do it!" mentality. Everyone has to show off their latest/greatest "ooooh shiny!" construction.

 

Wait... so PHP == insert language of choice to bash now?

*ducks*

Yes, I can see its similarity to VB.  

Java and PHP and COBOL (yes) being my languages of choice, I would not argue that there are many yahoos out there creating things like this in my favorite languages.

MarcB:

I really wonder what it is about PHP posts that makes people show off how bad their coding skills are by filling the comments section with useless blather. Especially useless blather of the "reimplementing the wheel by using square rocks" type. Must be something about the "PHP is so easy, even a braindead rotten paramecium can do it!" mentality. Everyone has to show off their latest/greatest "ooooh shiny!" construction.

As a PHP developer it is because I honestly believe 99% of PHP devs are complete retards.  It's the VB of Web 2.0.  It's fairly easy to grasp, has good online documentation, is installed on almost any shared host and has lots of free tools, plugins and libraries.  That means it attracts the lowest common developer.  There are so many code samples available for free that you can copy-and-paste your way to a buggy, slow web app in a matter of hours.

 

I think the language itself is pretty strong, though.  It's fast and has a pretty clean syntax.  It has tons of good extensions, is great at string manipulation and has primitve vectors/hashes.  I think of it as perl without the cruft and obfuscation.  It has an object model similar to Java's but with bits of Python-esque dynamism.  PHP 6 is shaping up to be a trainwreck, though.  We get goto statements (yes, goto) and namespaces (how the fuck is that gonna work?) but still no 64-bit ints.  Fantastic.

morbiuswilters:

I think the language itself is pretty strong, though.  It's fast and has a pretty clean syntax.

 

I've got lots of quibbles with PHP, but mostly to do with the core design of the language - not the functionality it provides, but how it's provided. Especially the total lack of cohesiveness in function naming: is_array (note the _), isset (note the lack of _), gettype, etc... The error reporting needs a lot of work too. I If you have an unbalanced bracket/brace, PHP will happily run to the end of the file and tell you that you've reached a premature EOF. Perl's much more intelligent and can backtrack and suggest a possible location for the start of the unbalancing.

Then there's the outright moronic stupidity the language had in earlier revisions - I'm looking at YOU, register_globals and magic_quotes_gpc(). At least register_globals defaults to off now, and I hope like hell will be sliced out of the language with a rusty scapel and buried face down in a cask of holy water.

Also, there's the variable scoping business. Is there any other in-use language out there that doesn't automatically variables from a higher scope visible in the current scope? I can't really see the reason for this, unless it's some kind of bad outgrowth of register_globals, keeping those auto-globals from stomping on in-function vars.

morbiuswilters:

I think of it as perl without the cruft and obfuscation.

Not to get into a War of the Most Holy Language, but I think Perl's got at least major thing going for it that PHP should have implemented from the get-go: seperate name spaces for arrays, hashes, and scalars.

'course, I haven't tried version 6 yet. The last time I did anything of consequence in Perl was back in the 5.005 or so days.

morbiuswilters:

PHP 6 is shaping up to be a trainwreck, though.

I've deliberately avoided looking at any of the PHP6 wishlists/roadmaps, because I'm sure there's enough idiocy out there that the best of the list will get thrown out, and the stupidest ideas promoted as the greatest thing since sliced bread.

morbiuswilters:

We get goto statements (yes, goto)

Excellent. Maybe Swampie will be able to convert SSDS to PHP so it can pretend to be a web app and finally be entered into that Mashup. If a language doesn't support GOTO, it's not a real language, you see. And scary as it sounds (brown-trousers moment... oy), SSDS is by far better quality code than some of the example comments you see in the PHP docs pages.

morbiuswilters:

namespaces (how the fuck is that gonna work?)

I'll guess the namespaces will be a sort of pseudo-object notation. $namespace::variable != $othernamespace::variable

MarcB:

Especially the total lack of cohesiveness in function naming: is_array (note the _), isset (note the lack of _), gettype, etc...

Agreed.  There are also too many "convenience" functions that do nothing useful, pollute the namespace and bloat the executable.

 

MarcB:

I If you have an unbalanced bracket/brace, PHP will happily run to the end of the file and tell you that you've reached a premature EOF.

That's pretty silly.  PHP will catch almost any unbalanced bracket, brace or parens because there is sure to be an invalid bit of syntax on one of the next few lines.  Also, most IDEs will find that type of thing for you.  I use vim and even it shows me when I'm missing a delimiter.

 

MarcB:

Then there's the outright moronic stupidity the language had in earlier revisions - I'm looking at YOU, register_globals and magic_quotes_gpc().

Yeah, that was just unbelievable.  You have to wonder what the hell the PHP devs were thinking..

 

MarcB:

Also, there's the variable scoping business. Is there any other in-use language out there that doesn't automatically variables from a higher scope visible in the current scope? I can't really see the reason for this, unless it's some kind of bad outgrowth of register_globals, keeping those auto-globals from stomping on in-function vars.

This is actually one of the things I love about PHP.  Variable scoping is extremely clear and you don't have to go tromping through dozens of files to see where a variable is changed.  It makes using global variables a lot cleaner and less error-prone, so long as you actually use it right.  Obviously, that easiness has the side effect of rampant global variable abuse by idiots..

 

MarcB:

Not to get into a War of the Most Holy Language, but I think Perl's got at least major thing going for it that PHP should have implemented from the get-go: seperate name spaces for arrays, hashes, and scalars.

Wow, I almost mentioned that as one of my favorite PHP features but was too lazy to try to fit it in.  I guess it's a case of different strokes for different folks, but I like that variable access is always done the same way.

 

MarcB:

I've deliberately avoided looking at any of the PHP6 wishlists/roadmaps, because I'm sure there's enough idiocy out there that the best of the list will get thrown out, and the stupidest ideas promoted as the greatest thing since sliced bread.

I've been following it for a two years and you're basically right on the mark. 64-bit ints are "not the PHP way" but gotos are.  Great.

 

MarcB:

If a language doesn't support GOTO, it's not a real language, you see.

Sadly, this was pretty much the rationale used by the core developers.  They admitted goto is awful, has no place in a procedural scripting language and will likely be abused.  However, they are including it for "completeness".

 

MarcB:

I'll guess the namespaces will be a sort of pseudo-object notation. $namespace::variable != $othernamespace::variable

That's basically it, but they have to introduce a new bit of syntax to handle it since they've already used the double-semicolon for statics.  I see a real mess with this, though, because PHP has such flexible scoping rules.  You include an external file and now it's in your scope, whatever that scope is.  If the namespaces are to prevent function/class name collisions, this will really complicate things.  They will probably work their way out of it somehow, but it just feels like another useless feature.  I've never had a problem with name collisions and if I did it would take a simple script to find-and-replace the offending names with unique ones.

Syntax-wise, I think the perfect language is somewhere between Perl and PHP. Perl could stand to lose some of the weird functions and stuff that looks Linux-specific, and I'm not sure if arrays and hashes really need to be separate data types, but I like its variable scoping much better than PHP's. PHP, however, actually has a sane way of taking parameters in a function. They both have a lot of strange workarounds that have built up over the years.

MarcB:

morbiuswilters:

We get goto statements (yes, goto)

Excellent. Maybe Swampie will be able to convert SSDS to PHP so it can pretend to be a web app and finally be entered into that Mashup. If a language doesn't support GOTO, it's not a real language, you see. And scary as it sounds (brown-trousers moment... oy), SSDS is by far better quality code than some of the example comments you see in the PHP docs pages.

I just had to go check and make sure there was no Inline::VisualBasic module.

MarcB:

Also, there's the variable scoping business. Is there any other in-use language out there that doesn't automatically variables from a higher scope visible in the current scope?

Even more confusingly, it automatically brings variables from a lower scope (e.g., vars declared inside "if" statements) into the higher, something I haven't seen any other languages do.

Anybody have thoughts on this?

morbiuswilters:

That's pretty silly.  PHP will catch almost any unbalanced bracket, brace or parens because there is sure to be an invalid bit of syntax on one of the next few lines.

I'm not saying it doesn't catch it - it does, it just spews out totally useless diagnostic information in the error report. For instance, on the 400+ line script I'm noodling around on for work, I stuck an unbalanced "if (TRUE) {" at line 85 and PHP's diagnostic output is: 

PHP Parse error:  syntax error, unexpected $end in scriptname.php on line 402 

(this is PHP 5.1.6). 

From the "unexpected $end" you can infer there's an unbalanced bracket somewhere, but all you can do is hop back into vi and bounce around with % until you find one where you bounce into a brick wall. I can't recall Perl's exact syntax, but it would say something like "Unbalanced {, possibly around line 80". It may not always have been right about the line number, but at least it explicitly tells you it's an unbalanced bracket.

The exact same thing happens if you forget to close a heredoc (or have a typo in the opening/closing delimeter) or a string. On the plus side, any decent syntax highlighter will show you exactly where things blew up because of the unterminated heredoc/string - just look for where the expected rainbow goes wonky.

boolean:

Even more confusingly, it automatically brings variables from a lower scope (e.g., vars declared inside "if" statements) into the higher, something I haven't seen any other languages do.

 

I refuse to dig into the PHP guts, but I'll postulate that this is due to PHP's scoping not being granular enough. Perl et-al will treat an if() or switch() block as its own little closure/subroutine, with its own scope (ignoring how vars were declared, as my() or local()). PHP's scoping begins/ends with function() and therefore everything within a function is within the same scope, except for nested functions, which again have their own scope.

A thought: Imagine PHP's scoping as granular as other languages. Do you think having to declare globals would last very long if you had to declare them every time you enter an if/switch block?

$x = 'blah';
if ($x == 'blah') {
    global $x;
    do_something($x);
}

.... scary. 

boolean:

Even more confusingly, it automatically brings variables from a lower scope (e.g., vars declared inside "if" statements) into the higher, something I haven't seen any other languages do.

Anybody have thoughts on this?

I don't think it's that confusing, just a little different.  In PHP, there is no lower scope in blocks -- any encountered variables are automatically added to the executing scope.  Any function or class declarations are automatically global as soon as their declaration is encountered in execution.

 

function func1($bool) {

    if ($bool) {

        function func2() { echo("wheee!\n"); }

    } 

}

 

func1($bool);

func2();

func1($bool); 

 

In this example, if $bool is false func2() will not exist and  the program will fatal on the call to func2().  If $bool is true, func2() will exist in the global scope and the string will be printed but it will fatal on the second call to func1() because it tries to redeclare func2().  This can lead to some pretty sloppy code, but it's all a matter of discipline -- you can write garbage in any language.  You just don't define functions inside other functions and you don't provide alternate definitions for functions.  One neat trick with this is that you can check to see if a function that was added in a later version of PHP exists and if not, provide your own implentation.  This is useful when writing libraries that need maximum compatibility.

 

I like the fact that PHP makes you explicitly reference variables by scope.  There is no ambiguity that $GLOBALS['foo'] is global, $_GET[' foo'] is from the query string, $this->foo is an instance member, self::$foo is a static class member and $foo is a local variable.  I find that it keeps things very clear and readable, but to each his own.

MarcB:

I'm not saying it doesn't catch it - it does, it just spews out totally useless diagnostic information in the error report.

I know what it does.  Normally I don't run into this because I'm writing classes and the open brackets are caught closer to the source instead of at the end of the file.  It is a tad annoying, though, but the only way to know where the problem is is to assume a standard formatting.  Most IDEs will flag stuff like this.  Since you are using vim, you can always use auto-format to quickly locate the unbalanced bracket.  Just highlight the entire section and hit '='.  It will reformat the code block.  Then you can just scan down your code and look for sections improperly contained within a block.  It should be pretty apparent when you have half your function contained within a while loop that was only supposed to be 3 lines that that is the source of the problem.  Just 'u' to undo the auto-format and correct the problem.  It's not the most elegant solution, but if you're pretty good with PHP and vim it shouldn't take much time or effort and it's a lot better than iterating over every bracket in the file with '%'.  I've had to work on lots of garbage legacy code written by braindead morons who couldn't be bothered to even indent correctly and this trick has saved me tons of time tracking down bugs. 

morbiuswilters:

Just highlight the entire section and hit '='.

 

Ah, if only I could. All my development is done on a remote server via ssh shells only. No vnc, no remote X, etc... Editing locally and then uploading takes far too long, especially when I'm doing layout tweaks. 2 seconds in vim on the remote server to change a css style parameter or whatever, v.s. 15+ to change locally + upload. It adds up quickly.

I've never resorted to the vim formatting options. There's been a few places where I had to format stuff crazily due  to code demands, but 99.99% of the time, everything's properly indented and auto-formatting would probably undo something I use as my normal style anyways.

MarcB:

From the "unexpected $end" you can infer there's an unbalanced bracket somewhere

Don't assume too much. The first time I got that message I went looking for what the hell this special variable $end was and how it got in my code. And if you're mocking PHP errors, you can't forget this one.

MarcB:

Ah, if only I could. All my development is done on a remote server via ssh shells only. No vnc, no remote X, etc...

What does that have to do with anything?  I do all of my editing in local terminals, the command should still work if you are using vim.  And a GUI on a UNIX server?  Blech..

 

MarcB:

I've never resorted to the vim formatting options. There's been a few places where I had to format stuff crazily due  to code demands, but 99.99% of the time, everything's properly indented and auto-formatting would probably undo something I use as my normal style anyways.

I'm not saying you use vim to format your code, just use the feature to locate the bug.  Below is a very simple example. 

 if ($cond1) {

    while ($cond2) {

    if ($cond3) {

    }

}

 

Now, obviously you can see the error in that because it's such a simple example.  Using vim to auto-format the code block will result in the following.

 if ($cond1) {

    while ($cond2) {

        if ($cond3) {

         }

   }

 

Now as you skim through the code the error should be much more visible.  Obviously everything after the while loop wasn't supposed to be in the while loop.  This is usually much easier to notice with a larger block of code because some condition or loop will contain every part of the function after it.  Now just hit 'u' to undo the auto-format.  Your code will revert and you can go in and add the bracket at the appropriate place.  There is no reason this shouldn't work in a local vim, a remove vim or gvim.  It's not perfect but it's a pretty quick way to locate the error.  Most graphical IDEs provide better support for catching formatting bugs, but I prefer vim personally.  Since this is ultimately a formatting issue (the parser has no way of knowing you didn't mean for all of that code to be in the while loop), I think it's better handled by developer tools and not the runtime parser.  Just my $0.02.