diff --git a/build_files/build_environment/CMakeLists.txt b/build_files/build_environment/CMakeLists.txt
index 343c0a79ea9..d08a287b5e3 100644
--- a/build_files/build_environment/CMakeLists.txt
+++ b/build_files/build_environment/CMakeLists.txt
@@ -94,7 +94,7 @@ if(NOT APPLE)
   if(NOT BLENDER_PLATFORM_ARM)
     if(HIP_FOUND)
       include(cmake/hiprt.cmake)
-    else()  
+    else()
       message(STATUS "Missing HIP compiler, skipping HIPRT build")
     endif()
     include(cmake/dpcpp.cmake)
diff --git a/build_files/buildbot/config/blender_windows.cmake b/build_files/buildbot/config/blender_windows.cmake
index 5d90dee6027..da0becd4efb 100644
--- a/build_files/buildbot/config/blender_windows.cmake
+++ b/build_files/buildbot/config/blender_windows.cmake
@@ -7,4 +7,4 @@ include("${CMAKE_CURRENT_LIST_DIR}/../../cmake/config/blender_release.cmake")
 set(WITH_CYCLES_TEST_OSL     ON CACHE BOOL "" FORCE)
 
 set(HIPRT_COMPILER_PARALLEL_JOBS        6 CACHE STRING "" FORCE)
-set(SYCL_OFFLINE_COMPILER_PARALLEL_JOBS 6 CACHE STRING "" FORCE)
\ No newline at end of file
+set(SYCL_OFFLINE_COMPILER_PARALLEL_JOBS 6 CACHE STRING "" FORCE)
diff --git a/doc/python_api/rst/info_gotchas_armatures_and_bones.rst b/doc/python_api/rst/info_gotchas_armatures_and_bones.rst
index c3aa7938451..52cdfafbdb7 100644
--- a/doc/python_api/rst/info_gotchas_armatures_and_bones.rst
+++ b/doc/python_api/rst/info_gotchas_armatures_and_bones.rst
@@ -97,5 +97,3 @@ clearly separates sections of the code which operate in different modes.
 
 This is mainly an issue with Edit-Mode since pose data can be manipulated without having to be in Pose-Mode,
 yet for operator access you may still need to enter Pose-Mode.
-
-
diff --git a/doc/python_api/rst/info_gotchas_file_paths_and_encoding.rst b/doc/python_api/rst/info_gotchas_file_paths_and_encoding.rst
index 946f3d3d62e..50940976df8 100644
--- a/doc/python_api/rst/info_gotchas_file_paths_and_encoding.rst
+++ b/doc/python_api/rst/info_gotchas_file_paths_and_encoding.rst
@@ -73,4 +73,3 @@ to keep it short about encoding problems -- here are some suggestions:
    when reading some input it's less trouble to read it as binary data
    though you will still need to decide how to treat any strings you want to use with Blender,
    some importers do this.
-
diff --git a/doc/python_api/rst/info_gotchas_internal_data_and_python_objects.rst b/doc/python_api/rst/info_gotchas_internal_data_and_python_objects.rst
index 52a6a2fffac..f2c76f84146 100644
--- a/doc/python_api/rst/info_gotchas_internal_data_and_python_objects.rst
+++ b/doc/python_api/rst/info_gotchas_internal_data_and_python_objects.rst
@@ -209,4 +209,3 @@ there is also no guaranteed compatibility in future releases.
 .. code-block:: python
 
    bpy.ops.wm.redraw_timer(type='DRAW_WIN_SWAP', iterations=1)
-
diff --git a/doc/python_api/rst/info_gotchas_meshes.rst b/doc/python_api/rst/info_gotchas_meshes.rst
index cfc04581352..253b760405e 100644
--- a/doc/python_api/rst/info_gotchas_meshes.rst
+++ b/doc/python_api/rst/info_gotchas_meshes.rst
@@ -109,4 +109,3 @@ the choice mostly depends on whether the target format supports n-gons or not.
   in fact this is the only place where their use is encouraged.
 - BMesh-Faces can work for exporting too but may not be necessary if polygons can be used
   since using BMesh gives some overhead because it's not the native storage format in Object-Mode.
-