opengl es2 – Implementation of a strange translation matrix

I am developing the OpenGLES 2.0 application for Raspberry Pi 3. I am new to OpenGL and OpenGL ES. I am currently learning OpenGLES in the book titled Programming Audio-Video GPU Raspberry Pi by Newmarch, January.

The authors Newmarch, Jan use the API implementation of the ES framework of the Apress OpenGLES 2.0 programming guide Aaftab Munshi et al. from here, the files Common directory contains the source files of the API structure.

Now the problem is that the API for the translation matrix is ​​implemented in a file. Common / esTransform.c As follows.
The API takes in 4×4 Identity matrix and stores newly calculated values ​​in the same matrix pointer variable.

esTranslate (ESMatrix * result, GLfloat tx, GLfloat ty, GLfloat tz)
result-> m[3][0]    + = (result-> m[0][0]    * tx + result-> m[1][0]    * ty + result-> m[2][0]    * tz);
result-> m[3][1]    + = (result-> m[0][1]    * tx + result-> m[1][1]    * ty + result-> m[2][1]    * tz);
result-> m[3][2]    + = (result-> m[0][2]    * tx + result-> m[1][2]    * ty + result-> m[2][2]    * tz);
result-> m[3][3]    + = (result-> m[0][3]    * tx + result-> m[1][3]    * ty + result-> m[2][3]    * tz);

If you tick the code above, the matrix indices are exchanged for LHS of the equation. The translation matrix will look like this if we enter the 4×4 identity matrix in the API:
begin {bmatrix}
1 & 0 & 0 & 0 \
0 & 1 & 0 & 0 \
0 & 0 & 1 & 0 \
tx & ty & tz & 1 \
end {bmatrix}

Looking at the matrix, it looks good, I only need to transpose before multiplying. Where as other implementation as esroter, esScale do not remove the transposed matrix. But is this minor problem that can be fixed.

These are my questions:

  1. Why do the first three elements have such a large equation?
    They should be:
    result-> m[3][0] + = tx; result-> m[3][1] + = ty; result-> m[3][2] + = tz; result-> m[3][3] = 1;
  2. Why the last element result-> m[3][3] is to have the equation? It's a homogeneous coordinate that should always be 1.
  3. If the API is correct, in which scenarios are these equations used?

Is my understanding of the translation defective? If an API is used up, then these API implementations have been on GITHUB for 7 years and strangely nobody has noticed the error?