[TASK] PANDAS [#4] (https://github.com/SENATOROVAI/DA/issues/4)

Python/clean-code/chapter_4_choosing_understandable_names.ipynb

@@ -0,0 +1,82 @@
+{
+ "cells": [
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "\"\"\"Chapter 4 - Choosing understandable names.\"\"\""
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "**Casing styles**\n",
+    "\n",
+    "Since Python identifiers are case-sensitive and cannot contain spaces, programmers use different naming styles to represent multiple words in an identifier:\n",
+    "\n",
+    "- Snake case: Words are separated with an underscores (_), which looks like a flat snake in between each word \n",
+    "(e.g., my_variable_name). All letters are lowercase, while constants are commonly written in upper snake case style \n",
+    "(e.g., MAX_CONNECTIONS).\n",
+    "- Camel case: Words are divided by capitalizing the first letter of each word after the initial one. Typically, the first word starts with a lowercase letter, and the capital letters in the middle mimic a camel’s humps \n",
+    "(e.g., myVariableName).\n",
+    "- Pascal case (PascalCase): Similar to camel case, but the first word also begins with a capital letter. This style is named after the Pascal programming language (e.g., MyClassName).\n",
+    "\n",
+    "Snake case and camel case are the most widely used styles. Although any naming convention can be selected, it’s important to stick to one consistently throughout a project."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "**PEP 8’s Naming Conventions:**\n",
+    "\n",
+    "- All letters should be standard ASCII characters — both uppercase and lowercase English letters without accent marks.\n",
+    "- Module names should be short and written in all lowercase letters.\n",
+    "- Class names should follow PascalCase formatting.\n",
+    "- Constant variables should be written using uppercase letters in SNAKE_CASE.\n",
+    "- Names for functions, methods, and variables should use lowercase snake_case.\n",
+    "- The first parameter in instance methods should always be named self (in lowercase).\n",
+    "- The first parameter in class methods should always be named cls (in lowercase).\n",
+    "- Private attributes in classes should always start with a single underscore (_).\n",
+    "- Public attributes in classes should never start with an underscore."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "**Best Practices and Useful Tips on Naming in Python**\n",
+    "\n",
+    "- Avoid using names that are too short (like h or aux) or unclear (such as start).\n",
+    "- Prefer longer, descriptive names that make the code easier to read (for example, totalAnnualRevenue).\n",
+    "- Short names are acceptable for loop counters (m, n, p) and coordinates (lat, lon).\n",
+    "- Don’t use unnecessary prefixes — use attribute access directly (for instance, Dog.age instead of dogAge).\n",
+    "- Avoid Hungarian notation (such as strTitle or bIsActive).\n",
+    "- For boolean values, use prefixes like is_ or has_ (e.g., is_valid, has_access()).\n",
+    "- Add units to variable names where relevant to avoid confusion (for example, distance_miles)."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "**Hold off on Overwriting Built-in Names in Python**\n",
+    "\n",
+    "- Don’t use Python’s built-in names (like list, input, max, id, etc.) for your variables.\n",
+    "- To check if a name is built-in, type it in the Python shell and see if it returns a function or object.\n",
+    "- Avoid giving your .py files the same name as existing modules (for example, naming a file json.py can shadow the real json module).\n",
+    "- If you encounter an unexpected AttributeError, it might be a sign that a built-in name was accidentally overwritten."
+   ]
+  }
+ ],
+ "metadata": {
+  "language_info": {
+   "name": "python"
+  }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 2
+}

Python/clean-code/chapter_4_choosing_understandable_names.py

@@ -0,0 +1,43 @@
+"""Chapter 4 - Choosing understandable names."""
+
+# **Casing styles**
+#
+# Since Python identifiers are case-sensitive and cannot contain spaces, programmers use different naming styles to represent multiple words in an identifier:
+#
+# - Snake case: Words are separated with an underscores (_), which looks like a flat snake in between each word
+# (e.g., my_variable_name). All letters are lowercase, while constants are commonly written in upper snake case style
+# (e.g., MAX_CONNECTIONS).
+# - Camel case: Words are divided by capitalizing the first letter of each word after the initial one. Typically, the first word starts with a lowercase letter, and the capital letters in the middle mimic a camel’s humps
+# (e.g., myVariableName).
+# - Pascal case (PascalCase): Similar to camel case, but the first word also begins with a capital letter. This style is named after the Pascal programming language (e.g., MyClassName).
+#
+# Snake case and camel case are the most widely used styles. Although any naming convention can be selected, it’s important to stick to one consistently throughout a project.
+
+# **PEP 8’s Naming Conventions:**
+#
+# - All letters should be standard ASCII characters — both uppercase and lowercase English letters without accent marks.
+# - Module names should be short and written in all lowercase letters.
+# - Class names should follow PascalCase formatting.
+# - Constant variables should be written using uppercase letters in SNAKE_CASE.
+# - Names for functions, methods, and variables should use lowercase snake_case.
+# - The first parameter in instance methods should always be named self (in lowercase).
+# - The first parameter in class methods should always be named cls (in lowercase).
+# - Private attributes in classes should always start with a single underscore (_).
+# - Public attributes in classes should never start with an underscore.
+
+# **Best Practices and Useful Tips on Naming in Python**
+#
+# - Avoid using names that are too short (like h or aux) or unclear (such as start).
+# - Prefer longer, descriptive names that make the code easier to read (for example, totalAnnualRevenue).
+# - Short names are acceptable for loop counters (m, n, p) and coordinates (lat, lon).
+# - Don’t use unnecessary prefixes — use attribute access directly (for instance, Dog.age instead of dogAge).
+# - Avoid Hungarian notation (such as strTitle or bIsActive).
+# - For boolean values, use prefixes like is_ or has_ (e.g., is_valid, has_access()).
+# - Add units to variable names where relevant to avoid confusion (for example, distance_miles).
+
+# **Hold off on Overwriting Built-in Names in Python**
+#
+# - Don’t use Python’s built-in names (like list, input, max, id, etc.) for your variables.
+# - To check if a name is built-in, type it in the Python shell and see if it returns a function or object.
+# - Avoid giving your .py files the same name as existing modules (for example, naming a file json.py can shadow the real json module).
+# - If you encounter an unexpected AttributeError, it might be a sign that a built-in name was accidentally overwritten.

Python/commits.ipynb

@@ -0,0 +1,125 @@
+{
+ "cells": [
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "id": "cd602499",
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "\"\"\"Ответы на вопросы по коммитам.\"\"\""
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "4875e71b",
+   "metadata": {},
+   "source": [
+    "1. Опишите своими словами назначение каждого из этих типов коммитов:\n",
+    "\n",
+    "    ```bash\n",
+    "    - feat - коммит, который добавляет определённую фичу в наш код;\n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - fix - коммит, который исправляет баг в нашем коде; \n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - docs - коммит, указывающий на изменения, связанные с документацией проекта; \n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - style - коммит, обозначающий изменения, связанные с оформлением кода (не влияя не его логику); \n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - refactor - коммит, указывающий на формальное изменение кода без изменения его логики\n",
+    "    (например, разделение больших функций на маленькие, улучшение алгоритмов и т.п.); \n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - test - коммит, обозначающий изменения, связанные с тестированием кода; \n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - build - коммит связан с изменениями, которые влияют на процесс сборки проекта или его зависимости; \n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - ci - коммит связан с изменениями в процессах непрерывной интеграции и развертывания (CI/CD); \n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - perf - коммит улучшает скорость работы или эффективность использования ресурсов\n",
+    "    (например, оптимизация алгоритмов, снижение потребление памяти и т.п.);\n",
+    "    ```\n",
+    "    ```bash \n",
+    "    - chore - коммит используется для решения технических задач, которые не влияют на код приложения и его функциональность (например, обновление зависимостей, очистка ненужных файлов и т.п.).`\n",
+    "    ```"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "27308307",
+   "metadata": {},
+   "source": [
+    "2. Представьте, что вы исправили баг в функции, которая некорректно округляет числа. Сделайте фиктивный коммит и напишите для него сообщение в соответствии с Conventional Commits (используя тип fix).\n",
+    "\n",
+    "    ```bash\n",
+    "    git commit -m \"fix: correct rounding issue in calculate_total function\"\n",
+    "    ```"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "fa3f2532",
+   "metadata": {},
+   "source": [
+    "3. Добавление новой функциональности:\n",
+    "Допустим, вы реализовали новую функцию generateReport в проекте. Сделайте фиктивный коммит с типом feat, отражающий добавление этой функциональности.\n",
+    "\n",
+    "    ```bash\n",
+    "    git commit -m \"feat: add generateReport function to create detailed reports\"\n",
+    "    ```"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "c3c01dfa",
+   "metadata": {},
+   "source": [
+    "4. Модификация формата кода или стилей docs:\n",
+    "Представьте, что вы поправили отступы и форматирование во всём проекте, не меняя логики кода. Сделайте фиктивный коммит с типом style.\n",
+    "\n",
+    "    ```bash\n",
+    "    git commit -m \"style: fixed indentation and formatting across the project\"\n",
+    "    ```"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "8f28fce4",
+   "metadata": {},
+   "source": [
+    "5. Документация и тестирование:\n",
+    "- Сделайте фиктивный коммит с типом, добавляющий или улучшающий документацию для вашей новой функции.\n",
+    "\n",
+    "    ```bash\n",
+    "    git commit -m \"docs: add documentation for generateReport function\"\n",
+    "    ```\n",
+    "\n",
+    "- Сделайте фиктивный коммит с типом test, добавляющий тесты для этой же функции.\n",
+    "\n",
+    "    ```bash\n",
+    "    git commit -m \"test: add unit tests for generateReport function\"\n",
+    "    ```"
+   ]
+  }
+ ],
+ "metadata": {
+  "kernelspec": {
+   "display_name": "venv",
+   "language": "python",
+   "name": "python3"
+  },
+  "language_info": {
+   "name": "python",
+   "version": "3.12.6"
+  }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 5
+}

Python/commits.py

@@ -0,0 +1,69 @@
+"""Ответы на вопросы по коммитам."""
+
+# 1. Опишите своими словами назначение каждого из этих типов коммитов:
+#
+#     ```bash
+#     - feat - коммит, который добавляет определённую фичу в наш код;
+#     ```
+#     ```bash 
+#     - fix - коммит, который исправляет баг в нашем коде; 
+#     ```
+#     ```bash 
+#     - docs - коммит, указывающий на изменения, связанные с документацией проекта; 
+#     ```
+#     ```bash 
+#     - style - коммит, обозначающий изменения, связанные с оформлением кода (не влияя не его логику); 
+#     ```
+#     ```bash 
+#     - refactor - коммит, указывающий на формальное изменение кода без изменения его логики
+#     (например, разделение больших функций на маленькие, улучшение алгоритмов и т.п.); 
+#     ```
+#     ```bash 
+#     - test - коммит, обозначающий изменения, связанные с тестированием кода; 
+#     ```
+#     ```bash 
+#     - build - коммит связан с изменениями, которые влияют на процесс сборки проекта или его зависимости; 
+#     ```
+#     ```bash 
+#     - ci - коммит связан с изменениями в процессах непрерывной интеграции и развертывания (CI/CD); 
+#     ```
+#     ```bash 
+#     - perf - коммит улучшает скорость работы или эффективность использования ресурсов
+#     (например, оптимизация алгоритмов, снижение потребление памяти и т.п.);
+#     ```
+#     ```bash 
+#     - chore - коммит используется для решения технических задач, которые не влияют на код приложения и его функциональность (например, обновление зависимостей, очистка ненужных файлов и т.п.).`
+#     ```
+
+# 2. Представьте, что вы исправили баг в функции, которая некорректно округляет числа. Сделайте фиктивный коммит и напишите для него сообщение в соответствии с Conventional Commits (используя тип fix).
+#
+#     ```bash
+#     git commit -m "fix: correct rounding issue in calculate_total function"
+#     ```
+
+# 3. Добавление новой функциональности:
+# Допустим, вы реализовали новую функцию generateReport в проекте. Сделайте фиктивный коммит с типом feat, отражающий добавление этой функциональности.
+#
+#     ```bash
+#     git commit -m "feat: add generateReport function to create detailed reports"
+#     ```
+
+# 4. Модификация формата кода или стилей docs:
+# Представьте, что вы поправили отступы и форматирование во всём проекте, не меняя логики кода. Сделайте фиктивный коммит с типом style.
+#
+#     ```bash
+#     git commit -m "style: fixed indentation and formatting across the project"
+#     ```
+
+# 5. Документация и тестирование:
+# - Сделайте фиктивный коммит с типом, добавляющий или улучшающий документацию для вашей новой функции.
+#
+#     ```bash
+#     git commit -m "docs: add documentation for generateReport function"
+#     ```
+#
+# - Сделайте фиктивный коммит с типом test, добавляющий тесты для этой же функции.
+#
+#     ```bash
+#     git commit -m "test: add unit tests for generateReport function"
+#     ```