Programming Language

From BC$ MobileTV Wiki
Jump to: navigation, search

A Programming Language is a formal language and method of controlling a machine (or type of machines) using instructions.

The following categories represent the most popular types of programming languages in existence today:



  1. Ruby
  2. C#
  3. ASP
  4. JSP
  5. PHP
  6. Python
  7. Perl


  1. Prolog
  2. F-logic
  3. Rule bases (for running Rule Engines)


  1. C
  2. Bash/Shell
  3. Batch/Powershell scripts
  4. IBM RPG


  1. Java
  2. C++
  3. Smalltalk



  1. Groovy (DSL syntax)
  2. Lisp
  3. SQL
  5. CSS
  7. XML/xHTML
  8. YAML

[2] [3] [4] [5] [6]


  1. jQuery



  1. JavaScript
  2. Scala
  3. LISP
  4. Assembly Language
  5. Machine Language
  6. APL

[8] [9] [10]


  1. Swift
  2. Kotlin
  3. Rx (various cross-platform libraries)

[11] [12]

Code Metrics

Software Quality Attributes (commonly abbreviated SQA) may potentially display visible symptoms externally when there are issues, but the argument of those who closely measure, monitor and maintain Code Metrics believe the roots of such problems are commonly invisible internal quality attributes such as: program structure, complexity, coupling, testability, reusability, readability, maintainability. There are many possible metrics to look into, however it is commonly accepted that Coupling, Complexity, Cohesion and Size are the fundamental internal quality attributes of a software program.

There are many ways of measuring and assessing these 4 fundametnal SQA, for instance, the following are the Code Metrics measured by CodeMR tool, which has become one of the leading OSS options (with a basic free product and more comprehensive commercial offering):

  1. Coupling - aim for lower coupling (impact of changes in one area to other areas, unintended side-effects, etc)
  2. LCohesion - Lack of Cohesion measures how well the methods of a class are related to each other. High cohesion (low lack of cohesion) tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.
  3. Complexity - Implies being difficult to understand and describes the interactions between a number of entities. Higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes.
  4. Size - one of the oldest and most common forms of software measurement. Measured by the number of lines or methods in the code. A very high count might indicate that a class or method is trying to do too much work and should be split up. It might also indicate that the class might be hard to maintain.
  5. CLOC - Class Lines of Code measures the number of all nonempty, non-commented lines of the body of the class. CLOC is a measure of size and also indirectly related to the class complexity.
  6. WMC - Weighted Method Count is the weighted sum of all class’ methods and represents the McCabe complexity of a class. It is equal to number of methods, if the complexity is taken as 1 for each method. The number of methods and complexity can be used to predict development, maintaining and testing effort estimation. In inheritance if base class has high number of method, it affects its' child classes and all methods are represented in sub-clasess. If number of methods is high, that class possibly domain spesific. Thefore they are less reusable. Also these classes tend to more change and defect prone.
  7. DIT - Depth of Inheritance Tree is the position of the class in the inheritance tree. Has 0 (zero) value for root and non-inherited classes.For the multiple inheritance, the metric shows the maximum length. Deeper class in the inheritance tree, probably inherit. Therefore, it is harder to predict its behavior. Also this class relatively complex to develop, test and maintain.
  8. NOC - Number of Children is the number of direct subclasses of a class. The size of NOC approximately indicates how an application reuses itself. It is assumed that the more children a class has, the more responsibility there is on the maintainer of the class not to break the children's behaviour. As a result, it is harder to modify the class and requires more testing.
  9. CBO - Coupling Between Object Classes is the number of classes that a class is coupled to. It is calculated by counting other classes whose attributes or methods are used by a class, plus those that use the attributes or methods of the given class. Inheritance relations are excluded. As a measure of coupling CBO metric is related with reusability and testability of the class. More coupling means that the code becomes more difficult to maintain because changes in other classes can also cause changes in that class. Therefore these classes are less reusable and need more testing effort.
  10. CBO_LIB - The number of dependent library classes.
  11. CBO_APP - The number of dependent classes in the application.
  12. RFC - Response For a Class is the number of the methods that can be potentially invoked in response to a public message received by an object of a particular class. It includes the full call graph of any method called from the originating method.If the number of methods that can be invoked at a class is high, then the class is considered more complex and can be highly coupled to other classes. Therefore more test and maintain effort is required.
  13. SRFC - Simple Response For a Class is the number of the methods that can be potentially invoked in response to a public message received by an object of a particular class. It includes methods directly invoced from the class. If the number of methods that can be invoked at a class is high, then the class is considered more complex and can be highly coupled to other classes. Therefore more test and maintain effort is required.
  14. LCOM - Lack of Cohesion of Methods measures how methods of a class are related to each other. Low cohesion means that the class implements more than one responsibility. A change request by either a Bug or a new feature, on one of these responsibilities will result in a change of that class, which greatly increases likelihood of further Regression Defects. Lack of cohesion also influences understandability and implies classes should probably be split into two or more subclasses.
  15. LCOM3 - varies between 0 and 2. Values 1..2 are considered alarming. In a normal class whose methods access the class's own variables, LCOM3 varies between 0 (high cohesion) and 1 (no cohesion). When LCOM3=0, each method accesses all variables. This indicates the highest possible cohesion. LCOM3=1 indicates extreme lack of cohesion. In this case, the class should be split. When there are variables that are not accessed by any of the class's methods, 1 < LCOM3 <= 2. This happens if the variables are dead or they are only accessed outside the class. Both cases represent a design flaw. The class is a candidate for rewriting as a module. Alternatively, the class variables should be encapsulated with accessor methods or properties. There may also be some dead variables to remove. If there are no more than one method in a class, LCOM3 is undefined. If there are no variables in a class, LCOM3 is undefined. An undefined LCOM3 is displayed as zero [1]. LCOM3 is calculated as follows: LCOM3 = (m - sum(mA)/a) / (m-1) where: m is number of procedures (methods) in class, a is number of variables (attributes) in class and contains all variables whether shared (static) or not, mA is number of methods that access a variable (attribute), sum(mA) is the sum of mA over attributes of a class.
  16. LCAM - Lack of Cohesion Among Methods (also referred to as "1-CAM")... CAM metric is the measure of cohesion based on parameter types of methods.
  17. NOF - Number of Fields (properties/attributes) in a class.
  18. NOM - Number of Methods in a class.
  19. NOSF - Number of Static Fields in a class.
  20. NOSM - Number of Static Methods in a class.
  21. SI - Specialization Index is defined as NORM # DIT / NOM... the Specialization Index metric measures the extent to which subclasses override their ancestors classes. This index is the ratio between the number of overridden methods and total number of methods in a Class, weighted by the depth of inheritance for this class. Lorenz and Kidd precise : Methods that invoke the superclass’ method or override template are not included.
  22. CM-LOC - Class-Methods Lines of Code is the total number of all nonempty, non-commented lines of methods inside a class.
  23. NoI - Number of Interfaces is the total number of Interfaces.
  24. NoCls - Number of Classes is the total number of classes in this project or specific module/package being examined.
  25. NoE - Number of Entities is the total number of Interfaces and classes.
  26. NORM - Number of Overridden Methods is the number of Overridden Methods.
  27. C3 - The max value of Coupling, Cohesion, Complexity metrics.
  28. nofP - Number of Packages in the project.
  29. nofPa - Number of External Packages is the number of External Packages referenced by the project.
  30. nofEE - Number of External Entities is the number of External classes and interfaces referenced by the project.
  31. NoPC - Number of Problematic Classes is the number of classes with high coupling, high complexity or low cohesion in the project.
  32. NoHPC - Number of Highly Problematic Classes is the number of classes with high coupling, high complexity and low cohesion in the project.
  33. LTCC - Lack of Tight Class Cohesion tric measures the lack cohesion between the public methods of a class. That is the relative number of directly connected public methods in the class. Classes having a high lack of cohesion indicate errors in the design.
  34. ATFD - Access to Foreign Data is the number of classes whose attributes are directly or indirectly reachable from the investiggated class. Classes with a high ATFD value rely strongly on data of other classes and that can be the sign of the God Class.
  35. I - Instability metric is used to measure the relative susceptibility of class to changes. It is defined as the ration of outgoing dependencies to all package dependencies and it accepts value from 0 to 1, and is calculated as follows: Instability = EC / (EC+AC) where: EC is Efferent Coupling measures "Outgoing Coupling" or the number of classes in other packages that the classes in the package depend upon is an indicator of the package's dependence on externalities, and, AC is Afferent Coupling measures "Incoming Coupling" or the number of classes in other packages that depend upon classes within the package is an indicator of the package's responsibility.
  36. Abs - Abstractness metric is used to measure the degree of abstraction of the package. abstractness is defines as the number of abstract classes in the package to the number of all classes.
  37. ND - Normalized Distance metric is used to measure the balance between stability and abstractness and is calculated as: ND = |Abs + I - 1|
  38. InDegree - In-degree of corresponding graph vertex of the class.
  39. OutDegree - Out-degree of corresponding graph vertex of the class.
  40. Degree - Degree of corresponding graph vertex of the class.

[13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

Code Ownership

[25] [26] [27] [28] [29] [30] [31] [32]


All of the codebase is owned by the entire Dev team, and responsibility for the quality is shared amongst all sub-teams and each of the team members equally. There are no leads in this model, everyone is considered to be at the same level for all changes.


The codebase is divided up into modules or logically related sections with each assigned a respective owner/lead and potentially a secondary lead if deemed necessary; but developers are allowed to change modules owned by other people through the team's defined Code Review process.


Very defined & intentional strategy where codebase is broken up into very granular modules (classes, functions, files) and each module assigned to one developer to take the lead and a secondary (as much as possible the "secondary" should be from another team), other devs then only allowed to make changes to modules they own or by special request to someone else's module; without such a request the owner or backup lead must be the ones to make the change.

Design Principles

[33] [34]



[35] [36] [37] [38] [39]






Coupling occurs between two classes A and B if:

   A has an attribute that refers to (is of type) B.
   A calls on services of an object B.
   A has a method that references B (via return type or parameter).
   A has a local variable which type is class B.
   A is a subclass of (or implements) class B.


Tightly coupled systems tend to exhibit the following characteristics:

   A change in a class usually forces a ripple effect of changes in other classes.
   Require more effort and/or time due to the increased dependency.
   Might be harder to reuse a class because dependent classes must be included.



Low Cohesion

High Cohesion

Design Patterns

[40] [41]

Creational Patterns



[43] [44]


Also commonly known as "Abstract Factory" pattern.

Factory Methods


Object Pool


Service Locator

Often combined with Factory pattern to implement a layer of interfaces between Server and Client.


Structural Patterns









Behavioral Patterns


Chain of Responsibility







Template Method




Model View Controller (commonly abbreviated MVC) is one of the most prevalent architectural approach for building complex UI-centric applications on the web, mobile or desktop. It evolved from a number of advances in computer science but is particularly attributed to Tygve Reenskaug

[47] [48] [49] [50] [51] [52] [53]




No Code

[54] [55] [56] [57]

Low Code

[58] [59] [60] [61] [62]

Cowboy Coding

Every man, woman and child for themselves mindset programming, reminiscent of the Wild West. Development done in a silo, using whatever tools, languages or technologies one prefers, with little to no consideration to team/dept/organizational fit, maintainability, or broader long-term business value. Usually no documentation or coding standards.

Rapid Prototyping

Chaos Coding

Anti-pattern to quality/productivity.


Requirements Driven Design, typically paired with Waterfall, depends on analysts to deliver complete, detailed requirements to programmers for implementation with little to no collaboration before this hand-off. Requirements must be vetted for business value before reaching developers.


Design Driven, all functionality, look & feel details provided up-front, just turn an existing diagram/drawing/wireframe/storyboard into something that works in real life as described.





Teaming up between two specific team members (typically developers, but could be a developer with a tester, or, a developer and designer) to collaborate on delivery of a specific Backlog item (Story, Task, Bug fix, Project, Feature, etc).

[63] [64] [65] [66] [67]

Mob Programming

Also known as "Boardroom Programming" or "mobbing". Can be an anti-pattern if not relegated to very specific problem-solving, and if not constituting a very small portion of total coding efforts/outputs. While the "go-to" shouldn't be mobbing for every single Backlog item or issue worked on, it should be a reliable technique to use particularly for new tasks where there is a higher than normal degree of uncertainty where a broad spectrum of ideas is likely to produce the best solution, and also the best cross-team knowledge sharing.

[68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88]



[90] [91] [92]

[93] [94] [95] [96] [97] [98]

[99] [100] [101] [102] [103]

[105] [106] [107] [108] [109] [110]

[112] [113] [114]





  • Emmet: | DOWNLOAD (HTML/CSS shortcut tool for web developers... type a CSS selecter/regex and auto-generate HTML templates or vice-versa CSS rules for a template)
  • Bubble: (info toolkit for data-driven apps/websites without code)


Top programming E-Learning resources/courses/services include:

[119] [120] [121] [122]



[128] [129] [130] [131] [132] [133]

[138] [139]

[140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152]

[153] [154] [155] [156] [157] [158] [159] [160] [161] [162]


External Links



  1. Object Design Checklist:
  2. wikipedia: Declarative programming
  3. The Complete Guide to Declarative Programming:
  4. Declarative programming -- When “what” is more important than “how”:
  5. CSS is a Declarative, Domain-Specific Programming Language:
  6. Object-Oriented CSS -- What, How, and Why: (technique to match a Declarative programming language like CSS to a more OO mindset)
  7. wikipedia: List of programming languages by category
  8. FP vs. OO List Processing:
  9. Functional Programming Patterns -- A Cookbook:
  10. Object-Oriented Programming — The Trillion Dollar Disaster: (opinion piece heavily favoring "Functional Programming" paradigms/languages over OOP)
  11. wikipedia: Reactive programming
  12. The Reactive Principles:
  13. Architectural Quality Assessment with CodeMR:
  14. Supported Metric List by CodeMR:
  15. What is the fascination with code metrics?:
  16. What code metric(s) convince you that provided code is “crappy”?:
  17. Visual Studio - Code metrics values:
  18. How to Generate code metrics data (in Visual Studio):
  19. Measure Your Code Using Code Metrics:
  20. A Survey of Metrics for UML Class Diagrams:
  21. Eclipse - Metrics plugin:
  22. How to Measure Code Quality - 7 Metrics Every Engineer Should Know:
  23. We Can't Measure Programmer Productivity… or Can We?:
  24. Measuring Software Complexity - What Metrics to Use?:
  25. Capitalism, Socialism, and Code Ownership:
  26. Martin Fowler on Code Ownership types:
  27. Martin Fowler - Shifting To Code Ownership:
  28. Weak Code Ownership in detail: (our team started out using this approach)
  29. DZONE - Code Ownership – Who Should Own the Code?:–-who-should
  30. Microsoft -- Don’t Touch My Code! - Examining the Effects of Ownership on Software Quality:
  31. Scaling Collective Code Ownership & Code Reviews at LinkedIn - Nikolai Avteniev:
  32. Capitalism, Socialism, and Code Ownership:
  33. The 7 Virtues of Good Software Design:
  34. Software Architecture Cheat Sheet for Daily Usage:
  35. Design Principles and Design Patterns - by Rob "Uncle Bob" Martin (2000):
  36. A Solid Guide to SOLID Principles:
  37. Why every element of SOLID is (according to this author) wrong:
  38. Solid Relevance: (Uncle Bob's response to Dan North's "Write Simple Code rather than following SOLID" talk)
  39. CUPID – the back story: (a bold claim that ever principle of SOLID is wrong)
  40. DesignPatterns implemented in JAVA:
  41. In28Mins -- Design Patterns for Beginners with Java examples:
  42. How to Build Creational Design Patterns: Singleton Pattern:
  43. Introducing the Single Element Pattern: | SRC
  44. WRITING TESTABLE CODEPRESENTATIONS Singletons are Pathological Liars:
  45. Design Patterns Explained – Service Locator Pattern with Code Examples:
  46. Usage of the Adapter pattern in Java:
  47. wikipedia: Trygve Reenskaug (researcher who coined the term "MVC")
  48. The original MVC reports Trygve Reenskaug Dept. of Informatics University of Oslo:
  49. The Model-View-Controller (MVC) -- Its Past and PresentTrygve Reenskaug, University of Oslo: | BACKUP
  50. MODELS - VIEWS - CONTROLLERS originakl 1979 whitepaper:
  51. Origins of Model View Controller:
  52. Do MVC like it’s 1979 (on iOS/Swift):
  53. Trygve Reenskaug's MVC specification applied to a Java Swing GUI app:
  54. New to "No Code"? Start Here:
  55. Stripe’s first no-code product -- Payment Links:
  56. Plasmic: (visual builder for your tech stack)
  57. AppSmith: (powerful open source framework to build internal tools)
  58. TechRepbulic -- REPORT - "Low-code" tech is the future for businesses and entrepreneurs:
  59. Is "Low-code" the best “new” technology breakthrough:
  60. 10 Best Low-Code Development Platforms in 2021:
  61. Introducing "Microsoft PowerFx" -- the low-code programming language for everyone:
  62. AppWrite: (Secure Open-Source Backend Server for Web, Mobile & Flutter Developers)
  63. Pair Programming and Why We Do It:
  64. Pair Programming (aka. Pairing):
  65. What Is Pair Programming?:
  66. A look at what "Pair Programming" is and its advantages/challenges:
  67. On Pair Programming:
  68. Teaching using Mob Programming:
  69. A Day of Mobbing:
  70. "Mob Programming" Time Lapse:
  71. A day of Mob Programming 2016:
  72. Mob Programming:
  73. Woody Zuill on Mob Programming and No Estimates:
  74. Agile Alliance -- Mob Programming – A Whole Team Approach (explained by Woody Zuill):
  75. GOTO 2017 conference -- Mob Programming - A Whole Team Approach (Woody Zuill):
  76. Mob programming and shared everything:
  77. Team-oriented development:
  78. How to Find the Right Collaborative Coding Tool for Remote Pair Programming:
  79. The Surprisingly Inclusive Benefits of Mob Programming:
  80. Mob Programming - the Good, the Bad and the Great:
  81. Speed Up Your Scrum With Mob Programming :
  82. How Mob Programming Will Make You More Effective:
  83. I did mob programming every day for 5 months -- here’s what I learnt:
  84. Mob Programming – A Whole Team Approach:
  85. InfoQ -- Mob Programming overview (VIDEO):
  86. Ping-Pong, Paired Programing (VIDEO):
  87. The Secret to a Great Planning Process — Lessons from Airbnb and Eventbrite:
  88. Don’t do Code Review, try Mob instead:
  89. 7 Brain Tips for Software Developers:
  90. The 7 Highest Paying Companies for Tech Workers in 2021:
  91. Why Don’t Tech Companies Pay Their Engineers to Stay?:
  92. The Argument for Location-Based Salaries Is Falling Apart:
  93. Cracking The Coding Interview - 12 Things You Need To Know:
  94. Top 10 OOP Concepts Interview Questions:
  95. 10 Tricky Core-Java Interview Questions:
  96. 7 Programmer Recruiting Mistakes:
  97. Resume Writing & Interviewing Skills:
  98. Unifying the Technical Interview:
  99. How to Prepare for Your DevOps Interview:
  100. Your DevOps Interview:
  101. What’s Your Favorite DevOps Interview Question? 20 DevOps Pros Share Their Favorite Questions and How Developers Can Prepare:
  102. DevOps interview questions: How to prepare:
  103. Top 8 DevOps Interview Preparation Tips:
  104. Database of JAVA interview questions:
  105. Most Frequently Asked Java Interview Questions:
  106. Top 20 Java Interview Questions by Hiring Investment Banks:
  107. Senior Developers are Getting Rejected for Jobs:
  108. The Best of Java Interview Questions:
  109. 50+ Java Interview Questions for Programmers:
  110. How Would You Answer This? "Tell Me About A Wrong Decision You've Made."​:
  111. Cracking the (Frontend) Coding Interview: (with old-school vanilla JS)
  112. Recruiting Software Developers – Coding Tests (are they needed, and how to prepare):
  113. My Salary Negotiation Strategy:
  114. Microsoft doubles budget for employee salaries to address inflation, retain talent :
  115. Tips for Onboarding and Training Employees With Disabilities:
  116. Codecademy, the free online coding school, raises another $30M led by Naspers:
  117. GLOT - Selenium Python "Headless Chrome" Test example:
  118. wikipedia: The Typing of the Dead
  119. Web Development Tools You Need to Know by the End of 2014:
  120. Top 20 Developer Tools of 2016:
  121. 17 key dev tools for 2017:
  122. Get your kids coding with Minecraft: | EXAMPLE
  123. Which programming languages are most popular (and what does that even mean)?:
  124. PYPL PopularitY of Programming Language:
  125. The 9 Most In-Demand Programming Languages of 2016:
  126. How Popular is JavaScript in 2019?:
  127. Sorting Algorithms visualized:
  128. Biased Algorithms Learn From Biased Data - 3 Kinds Biases Found In AI Datasets:
  129. Algorithmic Bias - Why Bother?:
  130. Bias In AI Algorithms:
  131. Babysitting Racist Algorithms:
  132. Google ‘fixed’ its racist algorithm by removing gorillas from its image-labeling tech:
  133. Google Searching For New Skin Tone Measures To Reduce Bias:
  134. Design patterns, the big picture, Part 1 -- Design pattern history and classification (Part 1 of 3):
  135. Design patterns, the big picture, Part 2 -- Gang-of-four classics revisited:
  136. Design patterns, the big picture, Part 3 -- Beyond software design patterns:
  137. A Software Developer’s Guide to Side Projects:
  138. Learn to Code with Star Wars:
  139. Minecraft Hour of Code Tutorials
  140. Martin Fowler -- Strangler Fig applications to software refactoring: (original post on the concept)
  141. Strangler Applications (examples/case-studies):
  142. Monolith to Microservices Using the Strangler Pattern:
  143. What is the Strangler Fig Pattern and How it Helps Manage Legacy Code:
  144. Sharing UI Components to Build Consistent UIs Faster:
  145. Switching from LESS to SASS with the Strangler Pattern:
  146. Strangler Applications:
  147. Chopping the monolith:
  148. The Strangler Pattern in Practice:
  149. The pros & cons of the Strangler architecture pattern:
  150. Microservice Strangler Pattern:
  151. What is the strangler pattern and how does it work?:
  152. Strangler Fig pattern:
  153. Naming Conventions From Uncle Bob's Clean Code Philosophy:
  154. 5 Tips to Master the Art of Clean Code:
  155. What Is Clean Code?:
  156. How to make your code better with intention-revealing function names:
  157. Why 4 spaces are used as the unit of indentation in Java?:
  158. Why are spaces preferred over tabs as indentation in Python?:
  159. Domain-Oriented Observability:
  160. The Clean Code Talks - Don't Look For Things!:
  161. 10 Must-Have React Developer Tools to Write Clean Code:
  162. Every second matters - the hidden costs of unoptimized "Developer workflows": (excellent chart of max. time to spend to save a certain amount of time, based on frequency of the task carried out)
  163. The Well-Grounded Java Developer:
  164. Eclipse Collections Kata:
  165. JVM Calendar -- 19 Lessons in a Kata:
  166. Code Kata:
  167. Elvis operator etymology:
  168. Tabs vs Spaces -- How They Write Java at Google, Twitter, Mozilla and Pied Piper:
  169. * Linus Torvalds on 80-character code limit being outdated, suggests 142:
  170. Refactoring comics/infographics:
  171. Leak of Microsoft Salaries Shows Fight for Higher Compensation:
  172. Changelog podcast #463 - 10,000 hours concept applied to development:

See Also

Programming Languages | IDE | E-Learning | Technology/TechDebt | Virtualization | Docker | OS | Device | Client/Server | API | Testing | CI/CD/CDD | DevOps | Agile | PM | Productivity | LAMP | MEAN | WebApp | DesktopApp | Mobile App