55- ** Strong Typing** : Use type hints extensively with MyPy. Avoid ` Any ` when possible
66- ** Type Safety** : Use dataclasses models for complex data
77 structures instead of untyped dictionaries
8- - ** CogniteResource** : Use ` CogniteResource ` for DTO (Data Transfer Object) that are request or response
9- objects to/from the Cognite API
10- - ** CogniteObject** : Use ` CogniteObject ` for objects that are within ` CogniteResource ` objects.
8+ - ** CogniteResource** : Use ` CogniteResource ` for DTO (Data Transfer Object) that are request or
9+ response objects to/from the Cognite API
1110- ** IO Safety** : Always use typed data structures for file operations and data parsing
1211- ** Readability** : Code should be immediately understandable
1312- ** Maintainability** : Write code that is easy to modify and extend
1413- ** Consistency** : Follow established patterns across the codebase
14+ - ** Code Comments** : Use comments sparingly. They should always add necessary context, or
15+ explain unintuitive code and never feel like a repeat of the code.
1516
1617## Principles on doing pull request reviews
1718
18- - ** Main point first. ** Start with the key feedback or required action.
19- - ** Be concise. ** Use short, direct comments. Avoid unnecessary explanations.
20- - ** Actionable suggestions. ** If something needs fixing, state exactly what and how.
21- - ** One issue per comment. ** Separate unrelated feedback for clarity.
22- - ** Code, not prose. ** Prefer code snippets or examples over long text.
23- - ** Background only if needed. ** Add context only if the main point isn't obvious.
19+ - ** Main point first** Start with the key feedback or required action.
20+ - ** Be concise** Use short, direct comments. Avoid unnecessary explanations.
21+ - ** Actionable suggestions** If something needs fixing, state exactly what and how.
22+ - ** One issue per comment** Separate unrelated feedback for clarity.
23+ - ** Code, not prose** Prefer code snippets or examples over long text.
24+ - ** Background only if needed** Add context only if the main point isn't obvious.
2425
2526## How to do pull request summaries
2627
27- - ** Short recap. ** Summarize the main point of the PR in one or two sentences.
28- - ** Don't repeat the PR description. ** Only add new or clarifying information.
29- - ** Be brief unless needed. ** Only write a longer summary if the PR description
28+ - ** Short recap** Summarize the main point of the PR in one or two sentences.
29+ - ** Don't repeat the PR description** Only add new or clarifying information.
30+ - ** Be brief unless needed** Only write a longer summary if the PR description
3031 is missing crucial details.
31- - ** Extend, don't duplicate. ** If more detail is needed, clearly state what is
32+ - ** Extend, don't duplicate** If more detail is needed, clearly state what is
3233 missing from the PR description and add only the necessary context.
3334
3435## Line Length and Formatting
@@ -73,7 +74,7 @@ import logging
7374from pathlib import Path
7475from typing import TYPE_CHECKING
7576
76- from requests import Response
77+ from httpx import Response
7778
7879from cognite.client.data_classes import Asset
7980
@@ -91,7 +92,8 @@ if TYPE_CHECKING:
9192
9293## Docstrings
9394
94- Use concise docstrings with Args/Returns in google-style format. Based on repository patterns:
95+ Use concise docstrings with Args/Returns in google-style format. 'Raises' can be used, but is not
96+ required. Based on repository patterns:
9597
9698``` python
9799def render_header (header : str ) -> str :
@@ -123,7 +125,8 @@ def walk_sdk_documentation(content: Tag, parser: Parser[T]) -> Iterable[T]:
123125## Error Handling
124126
125127- ** Specific exceptions** : Avoid broad ` Exception ` catches
126- - ** Graceful handling** : Provide meaningful error messages
128+ - ** Graceful handling** : Provide meaningful error messages, for example "got type foo,
129+ expected type bar".
127130- ** Type safety** : Return ` None ` or use Union types for fallible operations
128131
129132``` python
@@ -138,27 +141,6 @@ def validate_data_modeling_identifier(space: str | None, external_id: str | None
138141
139142- ** Pre-commit** : ` pre-commit run --all-files ` for comprehensive checks
140143
141-
142- ## Data Structures
143-
144- ** Prefer typed structures** :
145-
146- ``` python
147- # Good
148- @dataclass
149- class FunctionError :
150- function_name: str
151- message: str
152-
153- # Good
154- class QueryCompletion (BaseModel ):
155- query: str
156- variables: dict[str , Any]
157-
158- # Avoid
159- error_data = {" function_name" : " foo" , " message" : " bar" }
160- ```
161-
162144## Logging
163145
164146- Use the ` logging ` module with appropriate levels
@@ -192,6 +174,4 @@ error_data = {"function_name": "foo", "message": "bar"}
192174 guarantee against regression.
193175- Counter-intuitively, for data classes in the SDK, testing their load/dump
194176 methods should not be done as this is done automatically
195- (see ` tests/tests_unit/test_base.py ` ). This rule applies to any subclass of
196- ` CogniteObject ` , ` CogniteResource ` , ` CogniteUpdate ` ,
197- ` WriteableCogniteResource ` or ` WriteableCogniteResourceList ` .
177+ (see ` tests/tests_unit/test_base.py ` ). This rule applies to any subclass of ` CogniteResource ` or ` CogniteUpdate ` .
0 commit comments