blarApp / lsp-poc

3 stars 0 forks source link

Add relationships types #10

Closed berrazuriz1 closed 2 weeks ago

blar-app[bot] commented 2 weeks ago

https://app.blar.io/chat/665

PR Summary

This pull request introduces a series of refactoring changes aimed at improving the code organization and readability in several files. The modifications involve transitioning certain functionalities to more encapsulated structures and enforcing object-oriented programming principles. Key changes include:

  1. Refactoring the TreeSitterHelper class's get_reference_type function to utilize a Reference class instead of a dictionary.
  2. Moving the SymbolKind enumeration to the types folder for better project structure.
  3. Removing the main function from the LspCaller class, replacing it with a class method map_reference for formatting references.
  4. Introducing new classes Point, Range, and Reference using Python's dataclasses to better handle LSP references.

Each of these changes is intended to streamline the project by enhancing encapsulation and improving code clarity.

Key Findings

These changes and issues should be addressed to ensure robust, maintainable code.

Commit Reviews **Commit**: refactor: map lsp reference to a class #### Summary: - The commit refactors the function `get_reference_type` in the `TreeSitterHelper` class to utilize a `Reference` class instead of a dictionary for passing reference data, thus improving code readability and structure. This modification aligns with object-oriented best practices by encapsulating reference-related data within a defined class. #### Issues Found: 1. **Type: Potential Bug** - **Scope**: **TreeSitterHelper.py** in the **TreeSitterHelper** class on the **get_reference_type** function - **Description**: There is no validation or error handling mechanism to check whether the `named_parent` becomes `None` before it is used in `rel_types.get(named_parent.type, RelationshipType.USES)`. This might lead to an `AttributeError` if `named_parent` is `None`, as `None` doesn't have a `.type` attribute. - **Code Snippet**: ```python while named_parent is not None and named_parent.type not in rel_types: named_parent = named_parent.parent return rel_types.get(named_parent.type, RelationshipType.USES) ``` 2. **Type: Bad Practice** - **Scope**: **TreeSitterHelper.py** in the **TreeSitterHelper** class on the **get_reference_type** function - **Description**: The usage of `.get()` on `rel_types` with `named_parent.type` without confirming that `named_parent` is not `None`. It's generally advisable to check for `None` prior to accessing attributes. - **Code Snippet**: ```python return rel_types.get(named_parent.type, RelationshipType.USES) ``` 3. **Type: Bad Practice** - **Scope**: **TreeSitterHelper.py** in the **get_reference_type** function - **Description**: There should be a comment or documentation for `RelationshipType.USES` as a default. It is important in refactored code to provide such context for future maintainers. - **Code Snippet**: ```python return rel_types.get(named_parent.type, RelationshipType.USES) ``` **Commit**: refactore: pass SimbolKing to types folder #### Summary: - The commit involves refactoring by moving the `SymbolKind` enumeration into the `types` folder. `SymbolKind` is an enumeration of various code entity kinds, such as `File`, `Module`, `Class`, etc., implemented in Python using the `Enum` class. #### Issues Found: 1. **Type: Bad Practice** - **Scope**: **SymbolKind.py** file in the **LSP/types directory** - **Description**: The commit message contains a typo ("SimbolKing" instead of "SymbolKind") which can lead to confusion and issues with traceability in version control history. It is imperative to maintain accurate and clear commit messages. - **Code Snippet**: ```plaintext Commit: refactore: pass SimbolKing to types folder ``` This evaluation is based solely on the given description of the commit and changes identified within the `SymbolKind.py` transition. No direct issues with the code logic were found within the reviewed changes. **Commit**: refactor: erase name main code #### Summary: - The commit removes the `main` function and its related code from the `LspCaller.py` file. Additionally, it introduces a new method `map_reference` to the `LspCaller` class, which formats a given reference dictionary into a specific structure. This aligns with moving code structure responsibilities away from standalone script running to class-based operations, streamlining code organization. #### Issues Found: 1. **Type: Bad Practice** - **Scope**: **LspCaller.py** at the file level - **Description**: Direct removal of the `main` function can decrease immediate utility or testing capability. If `main` was used for standalone testing purposes, it should have been moved to a test or example script rather than removed entirely. - **Code Snippet**: ```python def main(): lsp_caller = LspCaller( root_uri="file:///home/juan/devel/blar/lsp-poc/ruby-on-rails-sample-app", # port=7658, ) lsp_caller.connect() if __name__ == "__main__": main() ``` 2. **Type: Bad Practice** - **Scope**: **LspCaller.py** in the `map_reference` method - **Description**: The `map_reference` method assumes that the `reference` dictionary will always contain "uri" and "range" keys without any validation or defaults. This could lead to KeyErrors if used with malformed input. - **Code Snippet**: ```python def map_reference(self, reference: dict) -> dict: return { "uri": reference["uri"], "range": reference["range"], } ``` Overall, the refactoring appears to streamline and enforce encapsulation within the `LspCaller` class but at the potential cost of losing direct executable testing embedded in the script. Validation around the new method `map_reference` should be considered. **Commit**: fix reference errors #### Summary: - The commit introduces a new `Reference` structure to encapsulate LSP references by utilizing Python's `dataclasses`. The commit adds new classes `Point`, `Range`, and `Reference` to handle references' attributes more explicitly and robustly. This not only organizes the code better but also significantly reduces the chances of reference-related bugs. #### Issues Found: 1. **Type: Bad Practice** - **Scope**: **Reference.py** file, in the `Reference` class initialization - **Description**: The `__init__` method of the `Reference` class directly accesses dictionary keys without verifying their existence. This could potentially cause a `KeyError` if the expected keys are missing from the input dictionary. While the usage of a dataclass promotes structure, incoming dictionary data should be validated robustly before accessing. - **Code Snippet**: ```python def __init__(self, reference: dict): self.range = Range( Point(reference["range"]["start"]["line"], reference["range"]["start"]["character"]), Point(reference["range"]["end"]["line"], reference["range"]["end"]["character"]), ) self.uri = reference["uri"] ``` The addition of structured data classes enhances clarity and enforces a stricter contract for reference attributes. However, input data to these structures should ideally be validated to prevent runtime errors.