An Entity is an object within our computer system that embodies a small set of critical business rules operating on Critical Business Data.

The use_cases module defines the business logic of the app. It is a part that is independent of the development platform, in other words, it is written purely in the programming language and doesn't contain any elements from the platform. In the case of Flutter, use_cases would be written purely in Dart without any Flutter elements. The reason for that is that use_cases should only be concerned with the business logic of the app, not with the implementation details.

interface_adapters is the layer outside use_cases. Interface Adapters crosses the boundaries of the layers to communicate with Application Business Rules, however, the Dependency Rule is never violated. Using polymorphism, Interface Adapters communicates with Application Business Rules using inherited classes: classes that implement or extend the UseCases presented in the Application Business Rules layer. Since polymorphism is used, the Gateways passed to Interface Adapters still adhere to the Dependency Rule since as far as Interface Adapters is concerned, they are abstract. The implementation is hidden behind the polymorphism.

The data module, which is a part of the outermost lib component, is responsible for data retrieval. This can be in the form of API calls to a server, a local database, or even both. Part of the Frameworks and drivers layer communicates directly with the platform in other words android and ios. Frameworks and drivers is responsible for Native functionality. Frameworks and drivers calls all Native APIs.

• DO use trailing commas for all function calls and declarations unless the function call or definition, from the start of the function name up to the closing parenthesis, fits in a single line.

• DON'T cast a nullable value to a non-nullable type. This hides a null check and most of the time it is not what is expected.

• PREFER using const for instantiating constant constructors

If a constructor can be invoked as const to produce a canonicalized instance, it's preferable to do so.

• DO sort constructor declarations before other members

• Avoid Mental Mapping

A single-letter name is a poor choice; it’s just a placeholder that the reader must mentally map to the actual concept. There can be no worse reason for using the name c than because a and b were already taken.

• Method names

Methods should have verb or verb phrase names like postPayment, deletePage, or save. Accessors, mutators, and predicates should be named for their value and prefixed with get…, set…, and is…

• Use Intention-Revealing Names

If a name requires a comment, then the name does not reveal its intent.

• Use Pronounceable Names

If you can’t pronounce it, you can’t discuss it without sounding like an idiot.

• Class Names

Classes and objects should have noun or noun phrase names and not include indistinct noise words:

GOOD:
Customer, WikiPage, Account, AddressParser.

BAD:
Manager, Processor, Data, Info.

• Functions should be small

Functions should hardly ever be 20 lines long. Blocks within if statements, else statements, while statements, and so on should be one line long. Probably that line should be a function call.

• Functions should do one thing

To know that a function is doing more than “one thing” is if you can extract another function from it with a name that is not merely a restatement of its implementation.

• One Level of Abstraction per Function

We want the code to read like a top-down narrative. We want every function to be followed by those at the next level of abstraction so that we can read the program, descending one level of abstraction at a time as we read down the list of functions.

• Dependent Functions

If one function calls another, they should be vertically close, and the caller should be above the callee, if possible.

• Use Descriptive Names

Don’t be afraid to make a name long. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.

• Function Arguments

The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible.

GOOD:
includeSetupPage()

BAD:
includeSetupPageInto(newPageContent)

• Flag Arguments

Flag arguments are ugly. Passing a boolean into a function is a truly terrible practice. It immediately complicates the signature of the method, loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another if the flag is false!

GOOD:
renderForSuite()
renderForSingleTest()

BAD:
render(bool isSuite)

• Explain Yourself in Code

Only the code can truly tell you what it does. Comments are, at best, a necessary evil. Rather than spend your time writing the comments that explain the mess you’ve made, spend it cleaning that mess. Inaccurate comments are far worse than no comments at all.

BAD:
// Check to see if the employee is eligible
// for full benefits
if ((employee.flags & hourlyFlag) && (employee.age > 65))

GOOD:
if (employee.isEligibleForFullBenefits())

• TODO Comments

Nowadays, good IDEs provide special gestures and features to locate all the //TODO comments, so it’s not likely that they will get lost.

• Public APIs

There is nothing quite so helpful and satisfying as a well-described public API. It would be challenging, at best, to write programs without them.

/// dart doc comment

• Commented-Out Code

We’ve had good source code control systems for a very long time now. Those systems will remember the code for us. We don’t have to comment it out anymore.

• Position Markers

In general, they are the clutter that should be eliminated—especially the noisy train of slashes at the end. If you overuse banners, they’ll fall into the background noise and be ignored.

// Actions //////////////////////////////////

• Don’t Return Null

When we return null, we are essentially creating work for ourselves and foisting problems upon our callers. All it takes is one missing null check to send an app spinning out of control.

• Don’t Pass Null

In most programming languages, there is no GOOD way to deal with a null that is passed by a caller accidentally. Because this is the case, the rational approach is to forbid passing null by default. When you do, you can code with the knowledge that a null in an argument list is an indication of a problem, and end up with far fewer careless mistakes.

• Classes Should Be Small!

With functions, we measured size by counting physical lines. With classes, we use a different measure. We count responsibilities. The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change. The name of a class should describe what responsibilities it fulfills. The more ambiguous the class name, the more likely it has too many responsibilities. The problem is that too many of us think that we are done once the program works. We move on to the next problem rather than going back and breaking the overstuffed classes into decoupled units with single responsibilities.

• Artificial Coupling

In general, an artificial coupling is a coupling between two modules that serves no direct purpose. It is a result of putting a variable, constant, or function in a temporarily convenient, though inappropriate, location. For example, general enums should not be contained within more specific classes because this forces the app to know about these more specific classes. The same goes for general purpose static functions being declared in specific classes.

• Prefer Polymorphism to If/Else or Switch/Case

There may be no more than one switch statement for a given type of selection. The cases in that switch statement must create polymorphic objects that take the place of other such switch statements in the rest of the system.

• Replace Magic Numbers with Named Constants

In general, it is a bad idea to have raw numbers in your code. You should hide them behind well-named constants. The term “Magic Number” does not apply only to numbers. It applies to any token that has a value that is not self-describing.

• Encapsulate Conditionals

Boolean logic is hard enough to understand without having to see it in the context of an if or while statement. Extract functions that explain the intent of the conditional.

GOOD:
if (shouldBeDeleted(timer))

BAD:
if (timer.hasExpired() && !timer.isRecurrent())

• Avoid Negative Conditionals

Negatives are just a bit harder to understand than positives. So, when possible, conditionals should be expressed as positives.

GOOD:
if (buffer.shouldCompact())

BAD:
if (!buffer.shouldNotCompact())

• Encapsulate Boundary Conditions

Boundary conditions are hard to keep track of. Put the processing for them in one place.

BAD:
if (level + 1 < tags.length) {
  parts = Parse(body, tags, level + 1, offset + endTag);
  body = null;
}

GOOD:
int nextLevel = level + 1;
if (nextLevel < tags.length) {
  parts = Parse(body, tags, nextLevel, offset + endTag);
  body = null;
}

• Constants versus Enums

Don’t keep using the old trick of public static final ints. enums can have methods and fields. This makes them very powerful tools that allow much more expression and flexibility.