Naming Conventions for Vanilla 2?

Mark

Hello Everyone!

I've finally left the drawing board for Vanilla 2 and started doing some programming tests to see if many of my ideas will pan out or not.

Since I'm basically starting from scratch, I've got some pretty basic questions that need answering. One of them is about naming conventions. I've written a blog entry about it and I'd love it if you guys took a look and shared your thoughts:

http://markosullivan.ca/blog/?p=43

PTVDesign

$variable_name = ''; function function_name($variable_name) {} class class_name { method_name($variable_name) {} } IMHO: don't use uppercase

y2kbg

vanilla 2 =) total sweetness i second the above suggestion because if caps give problem avoid it, otherwise i like you original VariableName

Fyorl

When I started programming PHP I always used stuff_like_this(); because that's what all my examples used. Since I've started writing extensions for Vanilla I've started following the conventions that you used. I don't know why but I think it makes my code look nicer and more readable - it feels less hacky.

If anything I would vote to stay with the same conventions you've got. I much prefer it. It also helps to separate core PHP functions from user-defined ones.

It also allows scope to make underscores more important (e.g. for prefixing extension functions to avoid namespace clashes).

I would also recommend reading about Hungarian Notation. It looks a bit like camelCase, which I hate but it could also be combined with your current notation and an underscore for some extra clarity: i.e. $uv_Name = ForceIncomingString('Name', ''); Would refer to an unsafe, unvalidated form string.

Mark

Hmmm. Interesting - I didn't expect that anyone would want me to keep my naming the same :) I was thinking about how I could accomplish my task and keep my naming the same last night, and I think it might be do-able. I'd still like to hear what more people think, though.

Max_B

I don't like camelCase, at all. I always though that underscore is more readable.
The initial capital for Class seems a good convention to me.

Exactly what you suggested in your blog in fact.

bobthecow

hungarian notation is the devil, imho. my vote is with ptvdesign's suggestion. if you feel you must use uppercase, use it for class names.

mattucf

I think naming conventions steal too much focus. It doesn't matter which convention you use, just that you have one.

There's a difference between readability and comfort, and I think when many people mention the former, they mean the latter.

Fyorl

Uh... can we have some justifications for these points please? Why do you think Hungarian Notation is 'the devil' and what type of Hunagarian Notation, there are two. Underscores take more keystrokes and make the variable name longer which is why I now prefer the Vanilla convention. I'd also prefer to capitalise the first name of every variable rather than just class names because it avoids camelCase.

timfire

Might I also suggest explicit conventions for extensions? I think it would be nice if functions and classes in extensions included the name of the extension, such as:

ExtensionName_FunctionName() {}

ExtensionName_ClassName {}

I don't know if there's ever been any clashes between extensions using functions/classes with the same name before, but requiring something like the above should prevent any clashes in the future.

Including the extension name in the variable name would be nice for important variables, but probably isn't necessary for all.

rel1sh

The first naming convention I was ever formally taught (and required to adhere to) was Camel Case: start variables, methods, and arguments with lower case; start class names with an upper case to denote their importance. I had no problem with it then and have no problem with it now. I think it generally aids reading of code and keeps it more "compact" on each line, as well as encouraging more meaningful variable name usage. The fact that it reminds me of programming in Java, however, is a slightly more sore subject.

Regardless, I definitely agree with timfire up above about leaning on extension authors to prevent the inevitable method or class name collision. Really, unless you have some technical hurdle which will prevent upper case characters in variable/method names, I'd say keep it as-is. The effort to convert at this point seems borderline obsessive.

Mark

The effort to convert at this point seems borderline obsessive.

There's nothing to convert. I'm starting from scratch.

awpti

I started with the camelcase methodology when I was a "young developer" (back in '98). Over time, I've found it's harder to maintain (read). I've only recently switched from camelCase to using_underscores. I find this; $my_var = specific_function($var_foo); is easier to read than; $myVar = specificFunction($varFoo) The advantage of staying away from camelcase is the VISIBLE seperation of words. You get to keep your semi-descriptive function naming while gaining readability and hence, maintainability. I like this document; http://expressionengine.com/docs/development/guidelines/general.html While it's specific to EE Addon Dev, it can be applied (and makes perfect sense) everywhere (I don't like EE myself, but the developers are fantastic). Also, consider making use of a Framework, such as Kohana (Fork of CodeIgniter, completely re-written and PHP5 strict). As an aside, consider the gophp5 movement. It's time for PHP4 to die a horrible, flaming death. (As an aside, I agree with a poster above - methodology is about comfort - but also still covers readability as much as it does comfort).

Fyorl

I think the reason for PHP 4 is that many hosts still don't offer PHP 5 support and so using PHP 5 would prevent a large group of people unable to use Vanilla on their sites. Rewriting Vanilla opens the possibility for having a PHP 5 version of Vanilla 2 and leaving Vanilla 1 for the PHP 4 users. As for frameworks, I don't really think that's a good idea. It adds a lot of code overhead that is a problem for things like forums which require fast page loads. Also, as projects get bigger, frameworks become more of a hindrance than a help - you find yourself bending your code around the framework to perform otherwise simpler tasks. Writing a framework for Vanilla from the ground up seems like a better idea as it allows all the code to be relevant and optimised to the tasks that Vanilla needs to perform. It does increase development time but I don't think that's a big issue here

awpti

I have, personally, not run into any need to 'bend' my methods to the whims of a framework (I use Kohana). It's flexibile and minimalist enough to let me do what I want while giving me a base of features that I don't feel like re-developing. As far as PHP4/PHP5 goes, there is absolutely no excuse for any host these days to not offer PHP5. People who use those hosts need to switch off to another host that has made a modicum of effort to move forward and support PHP5. V1 and V2 is a perfect time to split away from PHP4. Still running PHP4? Vanilla for you. Running PHP5? Vanilla 2 for you! The other side of the whole framework thing is just being able to yank the bits and pieces that you like right out of it. In simple apps where a framework would be bloated, I've managed to yoink some nice functionality away from CI/Kohana without breaking it. A framework would not be a bad idea for a project like this. Kohana is an example of a minimalist framework (unlike Cake or Symfony, et al). It has a core set of features. You build it up from there. If you get a chance, read up on it for the hell of it. I was against Framework for a LONG time until I ran across CodeIgniter and decided to give it a go. Used it for 6 months before shifting over to Kohana. It has easily halved the average time to go from an idea to functional code. In any case, just some potential suggestions. I don't know if Mark is going to be doing this as a public work with a group of core developers or himself. Hopefully the former, but if the latter, it's good to know he's taking suggestions and looking at available options. (Sorry for shifting slightly off-topic, but it doesn't to add input elsewhere)

Fyorl

Valid points, I've never used those frameworks before (I thought Symphony was a CMS, not a framework though) so I'm perfectly happy to believe what you're saying. I don't know for how large of a project you've used Kohana but in my experience frameworks are great for smaller projects, it's when you build bigger that they tend to get in the way. I don't think that has to be the case for all frameworks though so the possibility of a framework for Vanilla 2 shouldn't be ruled out.

awpti

In the end, this is obviously up to Mark. Would love to get his input on the overall discussion so far!

WallPhone

My host (1and1) is 4.4.7, but can do PHP5 with a .htaccess directive

I'm all for Vanilla 2 being PHP5, and will even help support Vanilla 1.x in PHP4 land.

MySchizoBuddy

Mark already has made the decision NOT to use php5. he made that clear on his blog post. as far as frameworks are concerned, making a new one for vanilla2 means we don't see vanilla untill next year. using frameworks gives us vanilla2 in matter of months. Don't want V2 to use full frameworks like (cake, codeignitor, kohana etc) prefer glue frameworks like Zend so there is NO overhead, use just the stuff you need. not to mention using Zend will give vanilla lot of eye balls and free promotion from zend itself. Zend supports tons of webservices, which means Vanilla can leverage them in a snap., flickr, google maps, amazon, delicious yahoo etc. these are real benefits for V2 users last Why reinvent the wheel, mark should spend time making cool features and implementing new ideas NOT making a new framework.

Minisweeper

MSB - "I’m pretty excited about where this is going and I think I’m going to continue on with PHP 5 to see where it takes me.".....that seems to me he IS using PHP5?

Dinoboff

@MySchizoBuddy: Check the good news: http://markosullivan.ca/blog/?p=44. About the framework. I would be happy if Mark were using Zend Framework 1.5 (Zend_Layout and the new partial helpers of Zend_View offer everything we need for vanilla); but Mark can use it's own MVC and DB framework, we can use any Zend component for our extensions.