3

I heavily rely on CFC. Sometimes within an application, I would have multiple CFC containing dozens of functions per CFC. So over time, it's easy to forget or miss out on already created functions.

So my question is how do you guys manage all these functions? Do you keep a separate document listing all the functions and indexing them that way? Is there an automated feature built in that we can use?

What I've been doing is naming functions more meaningfully but it's very tedious. There has to be a better way to do this. Just looking for your thoughts.

Thank you in advance.

MadushM
  • 397
  • 3
  • 17
  • 1
    Your methods should relate to the purpose of the class they're in. So if you have similar/same methods, then it suggests there's a possibility your class design has issues or could be finetuned? – Adam Cameron Oct 30 '14 at 22:25
  • 1
    We appreciate the irony of repeated reusable code. – Dan Bracuk Oct 31 '14 at 00:54
  • 1
    You might find this helpful: [How do you organize your small reusable cffunctions?](http://stackoverflow.com/q/624541/3524344) – Fish Below the Ice Oct 31 '14 at 12:40
  • @AdamCameron That is true, I agree and at the same time that is my fear as well. This is specially the case when dealing w/ applications/programs that you've now inherited. – MadushM Nov 03 '14 at 20:29
  • @FishBelowtheIce yes that link was helpful, thanks – MadushM Nov 03 '14 at 20:30

2 Answers2

7

I don't think there's a magic bullet here. Programmers with a bit more OCD than I will likely respond and give you an iron clad solution. For me (or my team) I keep a library of common components in a folder that I reuse for various sites and applications. Then I add them as a /util or /lib folder for a given project and use them (or extend them) as needed. Good planning - good documentation (a Wiki is a great choice for a team) is a must.

Planning carefully whether to extend a CFC is especially important. Otherwise you have to chase down nested function that are part of some super class way down in the weeds (as in, this works, but I really have no idea why it works).

This is where frameworks can provide much needed structure. For common functions and events they generally provide a location and a convention for creating such things. That makes them easy to decipher (as long as you've been indoctrinated into the framework). They have some downsides but they make life a lot easier :)

Mark A Kruger
  • 7,183
  • 20
  • 21
1

-You should follow the proper naming conventions for each and every cfcs.

-Each cfcs should be meant for a particular purpose. i.e. login cfcs should should only contain the login related functions.

-All common functions should be kept together in a cfc and that can be extended by the other cfcs.

-You can use a generic cfc for random functions.

Now, if you want to add a new function for any functionality then you can scan only 3 cfcs i.e. dedicated to that functionality, common and random. And you add the new as per the best fit.

Arun Pati
  • 125
  • 1
  • 9
  • I don't disagree with you Arun - sounds like a great system. But the devil is in the details and developers will disagree on "proper naming conventions" and what is (or is not) a "generic" CF function. We have an extensive best practice guide for our developers here, but we work with many teams externally. My Muse rule of thumb: _It is more important to **have** a thourough guide for development, and less important what it actually is._ If we could get folks to follow a documented standard (whether home grown or framework) we would have 3/4 of the battle won. – Mark A Kruger Oct 31 '14 at 16:06
  • I agree with you Mark. Use of a framework is always great. Also we should document our development guide. Which will be easy for the new developers to follow up. I should have more specific with words, I meant a proper name for each cfcs, from which you can get the related functionality easily. Generic means a common cfc which can store random functions like some algorithm which are not specific to any functionality, if the application have such. – Arun Pati Oct 31 '14 at 18:12
  • yep - we are on the same page I'm sure ;) – Mark A Kruger Oct 31 '14 at 18:30