Mobile

  • Architecture ASIS (iOS)

  • Code Quality

    Code Quality - Naming Conventions :

     

    Steve McConnell, Code Complete, The Power of Variable Names :

     

    I. Most Important Naming Consideration :

     

    The most important consideration in naming a variable is that the name fully and accurately describe the entity the variable represents. An effective technique for com- ing up with a good name is to state in words what the variable represents. Often that statement itself is the best variable name. It’s easy to read because it doesn’t contain cryptic abbreviations, and it’s unambiguous. Because it’s a full description of the entity, it won’t be confused with something else. And it’s easy to remember because the name is similar to the concept. Names should be as specific as possible. Names like x, temp, and i that are general enough to be used for more than one purpose are not as informative as they could be and are usually bad names.


    A good mnemonic name generally speaks to the problem rather than the solution. A good name tends to express the what more than the how. In general, if a name refers to some aspect of computing rather than to the problem, it’s a how rather than a what. Avoid such a name in favor of a name that refers to the problem itself.


    Names that are too short don’t convey enough meaning. The problem with names like x1 and x2 is that even if you can discover what x is, you won’t know anything about the relationship between x1 and x2. Names that are too long are hard to type and can obscure the visual structure of a program.

     

    II. Kinds of Names to Avoid :

     

    1. Avoid misleading names or abbreviations Make sure that a name is unambiguous. For example, FALSE is usually the opposite of TRUE and would be a bad abbreviation for “Fig and Almond Season.”
    2. Avoid names with similar meanings   Avoid variables with different meanings but similar names 
    3. Avoid names that sound similar, such as wrap and rap
    4. Avoid numerals in names (file1, file2,…)
    5. Don’t differentiate variable names solely by capitalization
    6. Avoid the names of standard types, variables, and routines
    7. Don’t use names that are totally unrelated to what the variables represent
    8. Avoid names containing hard-to-read characters

     

  • Google is working on a new OS called Fuchsia

    Google is working on a new OS called Fuchsia: not derived from the Linux kernel.

    Google is building a completely new operating system. 



    As in, not just an upgrade to Android or Chrome OS, but instead, a new system that’s not derived from the Linux kernel.


    https://github.com/fuchsia-mirror
    https://fuchsia.googlesource.com/

     

    The system use a Magenta Kernel base on LittleKernel (LK).
    LK is a Kernel designed for small systems typically used in embedded applications.

    "LK (Little Kernel) is a tiny operating system suited for small embedded devices, bootloaders, and other environments where OS primitives like threads, mutexes, and timers, but there’s a desire to keep things small and lightweight. On embedded ARM platforms the core of LK is typically 15-20 KB."

    Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation.


    https://github.com/littlekernel/lk/wiki
    https://fuchsia.googlesource.com/magenta/+/master/docs/mg_and_lk.md
    https://github.com/fuchsia-mirror/magenta/blob/master/docs/index.md



    As usual, it is open source project.

    I 'm anxious to know with which language we will develop on it : they will keep community and use swift or java? or they will invent a more simple and robust language that can suppress all existing programming languages?  
    The mobile world is changing, we assist to a revolution , what fun!

     

  • DESIGN PATTERN (MOBILE APPLICATION)

  • Les règles de codage - programmation défensive