Development / Developer rules

[ragtek]

What do you think about some rules for "us" (the 3rd party developer) ? I'm working as coder & code reviewer / QA, so rules are really important for me^^)

In the past, i had really bad experiance with some Add-ons (vB, mybb,..) the biggest was "same Function/Class Names & filenames".

There are many (smart) coder, which have own directories for there add-ons, but there are also many, which don't use own.

For example i've created in my library directory only one new directory "ragtek" and in this i create new directories for every new add-on, so i can go sure, that no other add-ons will have the same classnames or overwrite my add-on files.

So if we all would do it this way, there would never be this problems.
What do you think of this plan?
Have you better ideas/suggestions?

Maybe something like

• authorname/addonId
• or only addonId

I'm using allways the authorname first, because i had some "tools" for vB which created, edited,saved,build the package,... automatic for me and so i needed an namesspace for my tools, they could know where my add-ons are

 

[Laric]

The advantage as I understand it in XF is that we must use oop so the name clashes on functions is reduced as they are all contained in the class. Class names can clash of course but the chances are less likely.

 

[dmnkhhn]

XenForo uses CamelCase so you should create a directory called 'Ragtek'.

I like the idea of combining multiple add-ons from the same author in a dedicated directory.

class Author_MyAddon_ControllerPublic_Index extends XenForo_ControllerPublic_Abstract
{
}

Is it supported by XenForo?

 

[ragtek]

It was just a typo, i'm doing it correct and as you see, it's working^^ http://xenforo.com/community/threads/ragtek-contact-thread.5521/

 

[Shadab]

I also prefer a directory structure like: /library/<Vendor>/<AddOn>/*
So all classes of a particular addon will be prefixed by the vendor name and addon name.

For example,

• GeekPoint_FooThreads_*
• Ragtek_Blog_*
• King_StopForumSpam_* (hint hint)

This way all addons from a particular modification author can be found in a single directory. And we won't be littering our /library/ directory with multiple sub-directories. This goes in line with what already ships with xenforo in the library directory:

• /library/Sabre/
• /library/XenForo/
• /library/Zend/

with Sabre, XenForo and Zend being vendor names.

 

[Deceptor]

I personally like this structure, I (and team members) used this structure where possible in vB and now since XF autoloads we can keep everything in a directory which keeps it all nice and neat and more importantly seperate the primary XF files.

As it stands I'm using /library/DBTech/<Mod>/, and i'll definately keep it that way

 

[Jeremy]

I also prefer a directory structure like: /library/<Vendor>/<AddOn>/*
So all classes of a particular addon will be prefixed by the vendor name and addon name.

For example,

• GeekPoint_FooThreads_*
• Ragtek_Blog_*
• King_StopForumSpam_* (hint hint)

This way all addons from a particular modification author can be found in a single directory. And we won't be littering our /library/ directory with multiple sub-directories. This goes in line with what already ships with xenforo in the library directory:

• /library/Sabre/
• /library/XenForo/
• /library/Zend/

with Sabre, XenForo and Zend being vendor names.

Hey! Why was there a hint to me?! It does make sense, mainly because I will forget which add ons are which!

 

[Danny.VBT]

I like proposed structure of grouping Add-ons by vendor...but class names can become annoyingly long. (Eg; GeekPoint_FooThreads_Route_Prefix_Foo).

 

[Jeremy]

I like proposed structure of grouping Add-ons by vendor...but class names can become annoyingly long. (Eg; GeekPoint_FooThreads_Route_Prefix_Foo).

Yes, but we are the ones typing it, we don't have to do a bunch of including or anything, so I'm OK with longer file names. Although, I'm not sure I want KingKovifor_ file names... Yet King_ just doesn't seem right...

 

[ragtek]

Yea, the IDE makes the typing and the autoloader loads it, so i don't have a problem with it^^

And my nearly finished generator generates the file with the "class header" and method if i want^^

 

[Shadab]

I like proposed structure of grouping Add-ons by vendor...but class names can become annoyingly long. (Eg; GeekPoint_FooThreads_Route_Prefix_Foo).

Indeed. But what else can be done to prevent name conflicts when (re)using classes from different vendors? Many major library vendors for PHP use prefixes for this very reason; including CodeIgniter (CI_), Zend Framework (Zend_), symfony (sf), Doctrine (Doctrine_) & not to forget XenForo (XenForo_).

I know this could be an overkill for a lot of niche modifications when theres no scope of code reuse.

Yes, but we are the ones typing it, we don't have to do a bunch of including or anything, so I'm OK with longer file names. Although, I'm not sure I want KingKovifor_ file names... Yet King_ just doesn't seem right...

Coming up with a short but good name seems difficult than coding the actual thing.

 

[ragtek]

Finding good class names is sometimes really hard^^