The default values are component, event, and helper. It's in most (all?) of the documentation, and all of the default templates I've seen (e.g. when making a new controller). Some people shorten it to cmp, evt, and hlpr or something, but I don't see any good reason for that, given that we have decent autocompletion in most IDEs and we're not restricted to an ...
SFDC stands for SalesForceDotCom. The company would have retained just SF. But as trends on Social Communities started getting wider the acronym faced the uncertainty of getting hijacked by other trends.
For ex: Initially on Twitter, Salesforce used both #Salesforce and #SF as hashtags to monitor the interactions. Later, it got too crowded to use #SF since ...
Even though it depends on teams to teams when it comes around best practices, but as for your question
Any thoughts on what makes for good naming conventions for a pile of Custom Labels?
I have usually taken an approach of reflecting the intent of the custom label in its name. Have also tried to keep the naming convention seamless so that it can be ...
The most important part is consistency: don't name one label ERR_TOO_MANY_FILES and another VALUE_TOO_LONG_ERR. In my opinion, that's more important than trying to find the "one right way" (there isn't one). Document your naming convention, and stick to it. Also, aside from naming, make sure you're using the Categories field for each label. This will allow ...
To be honest I would extremely advice against using single letters for the component/event/helper.
Single letter is a sign for local variable. Eg: i for iteration.
I agree that those 3 are referenced a lot but making them single letters in my opinion makes code less readable.
Maybe because I was touching a lot of languages and technologies I'm opposing ...
Short answer is no, you can't do that. That being said, best practice is to NOT let users create folders. This practice is established for exactly the reason you mentioned.
As for reports. The report name shouldn't be controlled like that. The report name is not for the admin, its for the users who need the reports and the names need to make sense to those ...
I only deal with lightning components now and found it much easier to always stick to component, event, helper in their full format. I find that shortening it obfuscates unnecessarily for new lightning devs (and there will be many incoming). I even use make of _self as the variable reference in my helper class instead of this just so there's no doubt what ...
I'm mobile, but it seems to me that the first four parts could read like this:
// field1 is blank, field2 is blank
// field1 is blank, field2 is not blank
// field1 is not blank, field2 is blank
This is just a start, and not nearly a complete optimalisation. If statements 3, 4 and 5 have the same outcome, namely:
Show_Code__r.Name & "_" &
SUBSTITUTE(VenueCity__c," ","") & "_" &
TEXT(Month(Show_Close_Date__c)) & "." &
TEXT(DAY(Show_Close_Date__c)) & "." &
Right(text(YEAR(Show_Close_Date__c)),2) & "_" & ...
The naming convention depends on your organization's development style. The most important part about using naming conventions is to have a naming convention. It doesn't really matter what it is, so long as there's an easy way for people to go back and look them up.
For example, at one place I worked, we had a deployment exactly every two months, ...
The naming convention depends more on the kind of project/work (administration/development) you do to do the migrations.
For administration works, we usually get change requests and a single change request may require us to work on more than one type of component(workflow, process, apex class, trigger, visualforce, custom labels, etc.,). So ...