Best Practices And Coding Conventions practice questions

Use a single quote for the entire block.

Why wrong: Triple quotes are required for docstrings.

The docstring should span three lines including the summary.

Why wrong: That is for multi-line docstrings.

The summary should start on the next line.

Why wrong: PEP 257 suggests keeping it on the same line for brevity.

PascalCase.

Why wrong: Used for class names.

snake_case.

Why wrong: Used for functions and variables.

CamelCase.

Why wrong: Used for class names.

Use bare 'except:' for performance optimization.

Why wrong: Performance gain is negligible and risks instability.

Use 'except Exception:' as the standard catch-all.

Why wrong: It is safer than bare, but still broad; catching specific exceptions is better.

Use 'except:' but log the error immediately.

Why wrong: Logging does not fix the issue of catching signals like Ctrl+C.

Wrap the file operation in a try-except block.

Why wrong: This does not guarantee closure if an exception isn't caught or if the block is exited early.

Manually call file.close() in a finally block.

Why wrong: While 'finally' works, the 'with' statement is more idiomatic and concise.

Rely on the garbage collector to close the handle.

Why wrong: Garbage collection is non-deterministic and should not be relied upon for resource release.

Use a mixin class without inheritance.

Why wrong: Exceptions must inherit from a BaseException-derived class.

Inherit from StandardError.

Why wrong: StandardError does not exist in Python 3.

Inherit from BaseException.

Why wrong: BaseException is for system-exiting exceptions like KeyboardInterrupt.

Pass the entire input string to os.system().

Why wrong: os.system() is inherently vulnerable to shell injection.

Concatenate the input string into a shell command for execution.

Why wrong: This leads to command injection vulnerabilities.

Sanitize input using a custom regex to remove special characters.

Why wrong: Blacklisting is prone to bypasses; structural separation is safer.

Embed the types directly in the function name.

Why wrong: This violates naming conventions and increases cognitive load.

Include type hints in the docstring but omit them from the function signature.

Why wrong: Function signatures should use type hints for modern Python code.

Avoid documenting types to prevent redundancy with type hints.

Why wrong: Docstrings provide context that type hints alone cannot capture.

Use tabs exclusively, as they are more efficient for file size.

Why wrong: While tabs are valid in Python, PEP 8 recommends spaces.

Always use a combination of tabs and spaces to allow personal editor configuration.

Why wrong: PEP 8 explicitly discourages mixing tabs and spaces.

Default to the indentation used by the first author of the module.

Why wrong: Consistency should follow PEP 8, not just the first contributor.

80 characters.

Why wrong: 80 is often cited, but the PEP standard is 79.

No limit.

Why wrong: Line length limits are crucial for readability.

120 characters.

Why wrong: This is a common modern preference but not the strict PEP 8 rule.

By raising a warning if called externally.

Why wrong: This is intrusive and breaks the user experience.

By adding a comment like '# INTERNAL'.

Why wrong: Code conventions should be enforced by structure, not just comments.

By using all caps.

Why wrong: All caps are for constants.

By suffixing with an underscore.

Why wrong: Suffixing with an underscore is used to avoid conflict with reserved keywords.

Encrypt the secrets and store them as constants in a module.

Why wrong: The decryption key would still need to be stored somewhere, leading to the same problem.

Store secrets in a private class attribute.

Why wrong: Private attributes are easily accessible via introspection.

Hardcode them as strings inside a 'config.py' file and ignore it in Git.

Why wrong: This is error-prone and risks accidental commits.

Only unpickle from files with a specific extension.

Why wrong: Extensions provide no security against malicious file content.

Wrap the unpickling in a try-except block.

Why wrong: Exception handling cannot prevent the arbitrary code execution that happens during unpickling.

Use 'pickle.load()' with a restricted whitelist of modules.

Why wrong: Maintaining a secure whitelist for pickle is extremely difficult and prone to errors.

It is faster for small scripts.

Why wrong: Print is slightly faster, but logging is better for professional applications.

It prevents the application from crashing on errors.

Why wrong: Logging does not manage exception flow.

It automatically cleans up log files.

Why wrong: Log rotation is a feature, but it needs configuration.

When the file is in the same directory.

Why wrong: Relative imports are acceptable in the same directory, but absolute is still preferred.

Only if using Python 2.

Why wrong: Absolute imports are the standard for Python 3.

When performance is the main priority.

Why wrong: Import performance differences are negligible.

UPPER_SNAKE_CASE.

Why wrong: Reserved for constants.

camelCase.

Why wrong: Common in Java, but not standard for Python variables.

PascalCase.

Why wrong: Reserved for class names.

x= y +z

Why wrong: Spacing must be consistent.

x = y + z

Why wrong: Multiple spaces are discouraged.

x=y+z

Why wrong: Operators should have spaces around them.

Ensure All Functions Pass.

Why wrong: This is not a real principle.

Exit All Files Properly.

Why wrong: This relates to resource management, not error handling philosophy.

Evaluate All Faults Promptly.

Why wrong: This is not a standard coding philosophy.

Include the documentation as comments above the function definition.

Why wrong: Comments are for internal implementation details, not API documentation.

Provide usage examples in the 'README.md' file only.

Why wrong: While helpful, it is not a replacement for code-level documentation.

Wait for users to ask for documentation.

Why wrong: Professional libraries require proactive documentation.

Using a string literal (triple quotes) at the top level.

Why wrong: Triple quotes at the top level are often interpreted as docstrings.

Using block comments inside a single line.

Why wrong: Block comments should be distinct paragraphs.

Using a single '#' at the end of every line.

Why wrong: This is not standard.

__setup__ and __teardown__.

Why wrong: These are not part of the standard context manager interface.

__open__ and __close__.

Why wrong: These are not standard Python magic methods.

__init__ and __del__.

Why wrong: __del__ is for object destruction and should not be relied on for resource cleanup.