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

vanilla 2 =) total sweetness

i second the above suggestion because if caps give problem avoid it, otherwise i like you original

VariableName

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.

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.

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.

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.

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).

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)

In the end, this is obviously up to Mark.

Would love to get his input on the overall discussion so far!

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.

@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.

this would be a good time to create some demo themes for vanilla 2. one less work for mark
i like the theme of beast forum engine http://beast.caboo.se/

no i'm not saying to copy it. but something as simple as beast

I think any framework is better than nothing.

Why?

i hate creating forms for extensions. such a tedious work.

I'd like to second that, writing the configuration forms usually take longer than the actual functionality in my experience.

Re: Using a Framework

I have no strong opinion right now, but wasn't one of Mark's goals for V2 to shrink the core program? It seems that cutting out the framework would further that goal...

PS---I do like ThisTypeOfNamingConvention, now that I gotten used to it. It saves a few keystrokes over writing_with_underscores. But it's not a big deal. I am ambivalent towards camelCase. Pick one and go for it.