Return to Answer

##Maintainability

##Readability

##Example

##Update

Maintainability

Readability

Example

Update

##Update

As requested in comment. Using a while loop and more along the lines as I would write it to be consistent with internal standards. Please note this is not as maintainable if used in a general JS work environment.

const grouping = Object.freeze({ 
    maxSize: 50, 
    delimiter: " + ",
    prefix: "PUT ",   
    requests(reqs, {maxSize: max, delimiter: del, prefix: pre} = grouping) {
        var prev = {put: pre + reqs.shift().put};
        const grouped = [prev];
        while (reqs.length) {
            const next = reqs.shift().put;
            const putGroup = prev.put + del + next;
            if (putGroup.length <= max) { prev.put = putGroup }
            else { grouped.push(prev = {put: pre + next}) }
        }
        return grouped;
    },
});


const requests = [
    { put: "/firstName=Danny" },
    { put: "/lastName=Williams" },
    { put: "/[email protected]" },
    { put: "/address=1984 Some St, Very long named place. Woop Woop 6162" }
];

console.log( grouping.requests([...requests]));

• Use a consistent style throughout the code base. If the code is a group effort then that style must be established before the start of the project.

• For naming adopt the language standardized or informal style (Informal for JS as it does not have a standard style). In JavaScript we use camelCase variable names, Pascal_Case for instantiate-able objects via the new operator.

  For constants UPPERCASE_SNAKE with the general rule that we uppercase read-only properties of objects. Though many will also use them for all constants. There is no real consensus regarding the naming of constants but it is not good to be inconsistent in the use of UPPERCASE_SNAKE.

  Arrays, lists, and array like objects should use the plural name to indicate that it is more than one entity.

  Be consistent in naming items. Do not call the same abstract different names in different locations. EG you called the list of requests lists and group. You called a request insert and putGroup. (see example)

• Magic numbers and strings should be in one place so that they don't need to be hunted down to make changes. As they are separated from the code it pays to always comment these constants, include type, limits, and what they are used for. (see example)

  To ensure constants are not modified use object.freeze to make them read only. This instills trust in the state of the constants so the coder modifying the code does not have to hunt down each usage of the value to ensure it has not been modified if there are problems.

• Reduce the complexity by reducing operator and token counts. Eg if (!foo.length) { a = b } else { b = a } is better as if (foo.length) { b = a } else { a = b }

  Reduce the number of return points and keep it DRY. Eg in two places you create a new group and return it. With a little rearranging of the logic the two can be one. (see example)

• Use a consistent style throughout the code base. If the code is a group effort then that style must be established before the start of the project.

• For naming adopt the language standardized or informal style (Informal for JS as it does not have a standard style). In JavaScript we use camelCase variable names, PascalCase for instantiate-able objects via the new operator.

  For constants UPPERCASE_SNAKE with the general rule that we uppercase read-only properties of objects. Though many will also use them for all constants. There is no real consensus regarding the naming of constants but it is not good to be inconsistent in the use of UPPERCASE_SNAKE.

  Arrays, lists, and array like objects should use the plural name to indicate that it is more than one entity.

  Be consistent in naming items. Do not call the same abstract different names in different locations. EG you called the list of requests lists and group. You called a request insert and putGroup. (see example)

• Magic numbers and strings should be in one place so that they don't need to be hunted down to make changes. As they are separated from the code it pays to always comment these constants, include type, limits, and what they are used for. (see example)

  To ensure constants are not modified use object.freeze to make them read only. This instills trust in the state of the constants so the coder modifying the code does not have to hunt down each usage of the value to ensure it has not been modified if there are problems.

• Reduce the complexity by reducing operator and token counts. Eg if (!foo.length) { a = b } else { b = a } is better as if (foo.length) { b = a } else { a = b }

  Reduce the number of return points and keep it DRY. Eg in two places you create a new group and return it. With a little rearranging of the logic the two can be one. (see example)