Inconsistent docstring format across codebase

[yousefmoazzam]

Some docstrings use the google convention:

httomo/httomo/methods.py

Lines 20 to 30 in 8a55c4d

	def calculate_stats(
	data: np.ndarray,
	) -> Tuple[float, float, float, int]:
	"""Calculating the statistics of the given array
	Args:
	data: (np.ndarray): a numpy array
	Returns:
	tuple[(float, float, float, int)]: (min, max, sum, total_elements)
	"""

whereas other docstrings use the numpy convention:

httomo/httomo/method_wrappers/__init__.py

Lines 20 to 58 in 8a55c4d

	def make_method_wrapper(
	method_repository: MethodRepository,
	module_path: str,
	method_name: str,
	comm: Comm,
	save_result: Optional[bool] = None,
	output_mapping: Dict[str, str] = {},
	**kwargs,
	) -> MethodWrapper:
	"""Factory function to generate the appropriate wrapper based on the module
	path and method name. Clients do not need to be concerned about which particular
	derived class is returned.
	Parameters
	----------
	method_repository: MethodRepository
	Repository of methods that we can use the query properties
	module_path: str
	Path to the module where the method is in python notation, e.g. "httomolibgpu.prep.normalize"
	method_name: str
	Name of the method (function within the given module)
	comm: Comm
	MPI communicator object
	save_result: Optional[bool]
	Should the method's result be saved to an intermediate h5 file? If not given (or None),
	it queries the method database for the default value.
	output_mapping: Dict[str, str]
	A dictionary mapping output names to translated ones. The side outputs will be renamed
	as specified, if the parameter is given. If not, no side outputs will be passed on.
	kwargs:
	Arbitrary keyword arguments that get passed to the method as parameters.
	Returns
	-------
	MethodWrapper
	An instance of a wrapper class
	"""

Picking one convention and sticking with it feels better than having docstrings of various appearances in the source code.

[yousefmoazzam]

If we do decide to pick one convention to stick with, whatever convention is chosen, the tool ruff (which can be used as a formatter and/or a linter) can be configured to lint the code and check docstrings and ensure the chosen convention is adhered to.

The way ruff can be used is that it has reimplemented various python code quality checks (see the full list in: https://github.com/astral-sh/ruff?tab=readme-ov-file#rules), one of which is flake8-docstrings, which can be used to check that python docstrings adhere to a particular docstring convention.

Thus, ruff can be used to lint the code (in PR's for example) and check if the docstrings in the code adhere to the chosen docstring convention.