I know App::uses does lazy-loading, but if we are going to use i.e. CakeTime in a small part of our code (like inside an if statement that is called 1/3 of the times the method is called) then what would be the best place to put App::uses('CakeTime', 'Utility')?
The options are:
AppController
MyController
MyController::methodName
MyController::methodName inside the if statement (where it is actually going to be used).
I'm putting it in 4 as I guess there must be some obvious overhead (even if really small) but I don't see any reason for it to be present in every call of the controller. My colleague says 2 because it "we might need it elsewhere in the future and it lazyloads so it's not a problem". My answer to that is that if we need it elsewhere then we should redefine then where to put it according to the case.
What is your opinion and why?
There is no preferred place, only a "correct" place.
Always in the file where the class actually uses it.
So if you use CakeTime in your MyController, there is only the top of this very same file where you may put it.
Besides the technical aspect here it is also wise to do that for the coming up 3.0 version.
If you ever want to migrate (and thus to use namespace declarations) you will be more than grateful if you places those then former App::uses() statements in the correct places.
Related
I am new to Salesforce apex coding. My first class that I am developing has 10 methods and is some 800 lines.
I haven’t added much of exception handling, so the size should swell further.
I am wondering, what the best practice for Apex code is... should I create 10 classes with 1 method instead of letting 1 class with 10 methods.
Any help on this would be greatly appreciated.
Thanks
Argee
What do you use for coding? Try to move away from Developer Console. VSCode has some decent plugins like Prettier or Apex PMD that should help you with formatting and making methods too complex. ~80 lines/method is so-so. I'd worry about passing long lists of parameters and having deeply nested code in functions rather than just their length.
There are general guidelines (from other languages, there's nothing special about Apex!) that ideally function should fit on 1 screen so programmer can see it whole without scrolling. Read this one, maybe it'll resonate with you: https://dzone.com/articles/rule-30-%E2%80%93-when-method-class-or
I wouldn't split it into separate files just for sake of it, unless you can clearly define some "separation of concerns". Say 1 trigger per object, 1 trigger handler class (ideally derived from base class). Chunkier bits not in the handler but maybe in some "service" style class that has public static methods and can operate whether called from trigger, visualforce, lightning web component, maybe some one-off data fix would need these, maybe in future you'd need to expose part of it as REST service. And separate file for unit tests (as blasphemous as it sounds - try to not write too many comments. As you're learning you'll need comments to remind yourself what built-in methods do but naming your functions right can help a lot. And a well-written unit test is better at demonstrating the idea behind the code, sample usage and expected errors than comments that can be often overlooked).
Exception handling is an art. Sometimes it's good to just let it throw an exception. If you have a method that creates Account, Contact and Opportunity and say Opportunity fails on validation rule - what should happen? Only you will know what's good. Exception will mean the whole thing gets rolled back (no "widow" Accounts) which sucks but it's probably "more stable" state for your application. If you naively try-catch it without Database.rollback() - how will you tell user to not create duplicates with 2nd click. So maybe you don't need too much error handling ;)
I've just read the book called clean code. The author Uncle Bob talks about a single responsibility that a function should have in a program. It should only do one thing.
Now, I would like to understand how is it now possible to reuse a code that does multiple things. Let's say I have a method called runTrafficAndCheckIfItPassed and it calls two methods inside of it: runTraffic and checkIfTrafficPassed.
Now let's say that in my software I need to run traffic and to check it's result in a lot of places in my software. sometimes i need to check that traffic has failed, and sometimes i need to check if it passed.
Why wouldn't it be right to call the runTrafficAndCheckIfItPassed function and why is it way better to call the functions inside separately?
As far as I see, if there will be a change in the runTraffic function, for example to receive another parameter, the change will be implemented in one place, only in runTrafficAndCheckIfItPassed, which we see will be kinda easy to maintain.
But if i will use the functions seperately i will need to change it in any place.
But Bob says it's wrong? Got any examples or tips why it is called wrong?
I'm currently reading about modules in angular 2. In Angular documentation there is statement:
"A typical module is a cohesive block of code dedicated to a single purpose."
I want to figure out what they mean by a cohesive block of code?
Can someone explain it simply?
I googled, but I didn't found any good explanation which is simple.
Thanks!
I think in simple terms you can put it like this - In angular2 the application view is segregated into components. The components have their view and controller. Hence, it enforces better reuse.
I guess this means something like explained in Single responsibility principle
A class should do one thing and do it well.
A module it similar, just with a bit wider scope.
Cohesive means closely related or belonging together.
The concept of Cohesion: means the things that are related should always be part of one unit. They should go together this is called Cohesion.
I'm currently creating a code named "SET". The code's name is an acronym, which has been defined for many (non programming) reasons, and therefore cannot be changed.
Problem: The easiest, and I believe the less painful way for the end-user to use my code would be naming the package "set".
But of course this is a problem since this conflicts with the built-in set function.
Question: What are the possible solutions? Some may be (there is probably more):
change the package name (eg. setb).
import setb
I would really really prefer not to, because then it will be different from the real name
make the package's name upper-case (SET)
import SET
It would be a straight forward solution, but I'm wondering: is this a pythonic proper naming for a package? Also, I find this a bit painful since all modules defined in the code will have something like "import SET.x.y..." (ie. upper-case, written a lot of times). But this is not a really big deal if this is a pythonic way.
keep the name "set"
import set
Well this is obviously not fine. But it would be a problem only if the user is using "import set", would not it be? This should not happen in "normal usage conditions", since the code will provides some scripts to use it, rather use it as a standard python module. But we never know, and it could be imported as it, and there may be even some problems I'm not seeing (with the built-in set).
I'm considering the solution 2., but I'm really not sure. Maybe this is not proper, or maybe you guys have a better solution.
PS: I've found some similar topics on the web and on stackoverflow, but it usually deals with names inside a script or module inside a package. The problem here is really related to the code's name (which is meaningful only written this way), and therefore related to the proper naming of the package's name.
EDIT
Selected solution: I've choosen to use "SET" as the package name. Although many good suggestions have been proposed here: pyset, semt, setool... or the more explicit "starexoplanettool" (expliciting the acronym). Thanks to you all.
EDIT #2
I like the "funny" solution of having a package named S, and a subpackage, E... to get finally:
import S.E.T
Thanks Don Question.
Why not spell out the meaning behind the acronym, and if the user is desperate for a shorter name, they can do import someetymologyterm as SET or whatever they prefer. Python gives them the choice, so it's not the end of the world either way.
Is this a pythonic proper naming for a package?
Under the circumstances, it doesn't matter.
Leading upper case is rare (ConfigParser, HTMLParser). Camel-case is rare (cStringIO).
But that doesn't make all upper-case wrong.
It just means you should pick a better acronym next time.
"set" is the English word with the largest number of definitions. It is the single poorest choice of acronym possible.
The point is not to conform to a community "standard" of more-or-less acceptable behavior.
The point is to write something that works.
(ie. upper-case, written a lot of times).
Hardly a concern. People actually run software more often than they write it.
People read and tweak more often than writing, also.
If you're worried about misspelling, there's copy and paste.
Also, even a cheap IDE like Komodo Edit can figure out how to code-complete an installed module with a long name.
If you have to choose such a misfortunate name, you could make the pain in the ass an ironic anathema! Just create a main-package "S" with a subpackage "E" and therein a subpackage "T".
Then you could do an:
import S.E.T
or
from s.e.t import xyz
or
import s.e.t as set_
you could even do some vodoo in the __init__.py file of the main-pacakge ;-)
Just my 2 cents!
Maybe I'm not getting it but this looks simply like a namespace problem.
Here is one way out. Prepend the path to the set.py onto the sys.path Before the import takes place. You can wrap this in a function which backs out the change after the import.
I'm in train so can't test this but that is what I would try.
I have a question concerning the performance, reliability, and best practice method of using Extjs's update() method, versus directly updating the innerHTML of the dom of an Ext element.
Consider the two statements:
Ext.fly('element-id').dom.innerHTML = 'Welcome, Dude!';
and
Ext.fly('element.id').update('Welcome, Dude!', false);
I don't need to eval() any script, and I'm certain that update() takes into consideration any browser quirks.
Also, does anyone know if using:
Ext.fly('element-id').dom.innerHTML
is the same as
d.getElementById('element-id').innerHTML
?
Browser and platform compatibility are important, and if the two are fundamentally the same, then ditching Ext.element.dom.innerHTML altogether for update() would probably be my best solution.
Thanks in advance for your help,
Brian
If you do not need to load scripts dynamically into your updated html or process a callback after the update, then the two methods you've outlined are equivalent. The bulk of the code in update() adds the script loading and callback capabilities. Internally, it simply sets the innerHTML to do the content replacement.
Ext.fly().dom returns a plain DOM node, so yes, it is equivalent to the result of getElementById() in terms of the node it points to. The only subtlety to understand is the difference between Ext.fly() and Ext.get(). Ext.fly() returns a shared instance of the node wrapper object (a flyweight). As such, that instance might later point to a different node behind the scenes if any other code calls Ext.fly(), including internal Ext code. As such, the result of a call to Ext.fly() should only be used for atomic operations and not reused as a long-lived object. Ext.get().dom on the other hand returns a new, unique object instance, and in that sense, would be more like getElementById().
I think you answered your own question: "Browser and platform compatibility are important, and if the two are fundamentally the same, then ditching Ext.element.dom.innerHTML altogether for update() would probably be my best solution." JS libraries are intended (in part) to abstract browser differences; update is an example.
#bmoeskau wrote above, update() provides additional functionality that you don't need right for your current problem. Nevertheless, update is a good choice.