What is Closing Brace Comments ?

Closing Brace Comments

try {
while ((line = in.readLine()) != null) {
...
} // while
...
} // try

Although this might make sense for long functions with deeply nested structures, it serves only to clutter the kind of small and encapsulated functions that we prefer.

Attributions and Bylines

/* Added by Rick */

Source code control systems are very good at remembering who added what, when. There is no need to pollute the code with little bylines.

source : https://medium.com/@mosquitolwz/clean-code-quotes-4-comments-2de28ba0a6e2

Clean Code Summary

SOURCE https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.


General rules

  1. Follow standard conventions.
  2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
  3. Boy scout rule. Leave the campground cleaner than you found it.
  4. Always find root cause. Always look for the root cause of a problem.

Design rules

  1. Keep configurable data at high levels.
  2. Prefer polymorphism to if/else or switch/case.
  3. Separate multi-threading code.
  4. Prevent over-configurability.
  5. Use dependency injection.
  6. Follow Law of Demeter. A class should know only its direct dependencies.

Understandability tips

  1. Be consistent. If you do something a certain way, do all similar things in the same way.
  2. Use explanatory variables.
  3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
  4. Prefer dedicated value objects to primitive type.
  5. Avoid logical dependency. Don’t write methods which works correctly depending on something else in the same class.
  6. Avoid negative conditionals.

Names rules

  1. Choose descriptive and unambiguous names.
  2. Make meaningful distinction.
  3. Use pronounceable names.
  4. Use searchable names.
  5. Replace magic numbers with named constants.
  6. Avoid encodings. Don’t append prefixes or type information.

Functions rules

  1. Small.
  2. Do one thing.
  3. Use descriptive names.
  4. Prefer fewer arguments.
  5. Have no side effects.
  6. Don’t use flag arguments. Split method into several independent methods that can be called from the client without the flag.

Comments rules

  1. Always try to explain yourself in code.
  2. Don’t be redundant.
  3. Don’t add obvious noise.
  4. Don’t use closing brace comments.
  5. Don’t comment out code. Just remove.
  6. Use as explanation of intent.
  7. Use as clarification of code.
  8. Use as warning of consequences.

Source code structure

  1. Separate concepts vertically.
  2. Related code should appear vertically dense.
  3. Declare variables close to their usage.
  4. Dependent functions should be close.
  5. Similar functions should be close.
  6. Place functions in the downward direction.
  7. Keep lines short.
  8. Don’t use horizontal alignment.
  9. Use white space to associate related things and disassociate weakly related.
  10. Don’t break indentation.

Objects and data structures

  1. Hide internal structure.
  2. Prefer data structures.
  3. Avoid hybrids structures (half object and half data).
  4. Should be small.
  5. Do one thing.
  6. Small number of instance variables.
  7. Base class should know nothing about their derivatives.
  8. Better to have many functions than to pass some code into a function to select a behavior.
  9. Prefer non-static methods to static methods.

Tests

  1. One assert per test.
  2. Readable.
  3. Fast.
  4. Independent.
  5. Repeatable.

Code smells

  1. Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
  2. Fragility. The software breaks in many places due to a single change.
  3. Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
  4. Needless Complexity.
  5. Needless Repetition.
  6. Opacity. The code is hard to understand.

What is the best PHP comment ? Best PHP doc ?

Here is my typical php comment/header for each of my php functions. Very useful and pragmatic. They provide a clear indication what the function is doing, inputs, outputs and exceptions. This is the art of coding ! Clear readibility and full transparency on the intentions of the functions.

I would definitely make this a requirement for programmer team. Additional work but useful. And if it is an API I would use the zircote/swagger-php library to generate on the fly an amazing swagger documentation

/**
 * Throw Exception If Parameter Is Not Set
 *
 * @param object $requestObjectBody
 * @param int $httpCode
 * @param string $httpMessage
 *
 * @return void
 *
 * @throws \Exception $exception
 *
 * @author  David Raleche
 * @version 08-09-2019
 */
public static function throwExceptionIfParameterNotSet($param, int $httpCode, string $httpMessage)
{
    if (is_null($param) or empty($param)) {
        throw new \Exception(
            $httpMessage,
            $httpCode
        );
    }
}

CIO/Managers : When having interns in your company the first exercise to give them is to go trhough existing code and add the following blocs of PHP docs. This will help them understand the code and this will improve considerable the readability of the legacy code. By doing so we quickly pinpoint the function to refactor

I usually give them the task to refactor functions being too long. More than 50 lines

David Raleche PHP good practice
David Raleche PHP good practice php developers

What is the best practice for naming a REST endpoint ?

Lowercase letters and dashes

By convention, resource names should use exclusively lowercase letters. Similarly, dashes (-) are conventionally used in place of underscores (_).

Example: /users/{id}/pending-orders instead of /users/{id}/Pending_Orders

Source of information

Using a hyphen in your URLs is recommended by Google, because it makes your website easy to read for humans. As an end result, this means that your site will place better on search engines. Are you looking to learn more about how to improve the SEO of your blog?

How to fix wordpress Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2348617 bytes) in /wp-includes/plugin.php on line xxx?

Solution is to add the following line below to this file wp-config.php

define( 'WP_MEMORY_LIMIT', '256M' );

How to fix Satori issue 80040421 ?

The problem 80040421 is not always Unable to allocate any sequence numbers

This time the problem was missing permits to execute the presorting of the requests

The solution is to make sure these permits exists and the problem will go away

Also, If you have already done the configuration in the past know that the configuration file exists in the following folder C:/WINDOWS

The file name is mrtk.ini