This document aims to provide set of good practices that should be helpful for both developers and code reviewers. They should be treated like food recipies - you can play with them, alter them - but every change should be thoughtful and intentional. :::warning Remember that code review is discussion, don't hasistate to ask for clarification, help etc. Reviewer may be wrong and the goal is to make code to a point where all parties all happy. ::: In this document the bolded text will indicate how important each suggestion is. must will be used for fundamental things that should be non-controversial and which you really should follow should will be used for important details that will apply for vast majority of cases, there could however be valid reasons to ignore them depending on context

The goal of this document is to explore way of providing one modeling workbench to end users, instead of current situation where FreeCAD has two workbenches (Part and Part Design) that can achieve similar, but not quite exact things. Understanding the differences While offering users similar features the workbenches differ substantially in presented workflows. From user perspective we can list two most important differences: Feature organization Part workbench uses generic tree structure to organize features. This is very powerful but has some drawbacks like having deeply nested structures that can cause issues (see https://github.com/FreeCAD/FreeCAD/issues/7606). Part design on the other hand uses linear, timeline-like way of presenting features. The linear structure is special case of tree and hence can be easily represented in Part structure, the other way is non-trivial and may not always be possible.

Szybkośc ładowania się stron w aplikacji webowej może mieć wpływ na zyski 1. Dodatkowo mniejsze wykorzystanie zasobów może wpływać na zmniejszenie kosztów utrzymania (no tu chyba cytatu nie trzeba). W tej publikacji sugerujemy, że wybierając odpowiedni runtime możemy poprawić te dwie metryki bez ingerencji w aplikację. P1 Cel: Optymalizacja programowego środowiska wykonawczego aplikacji - bez kubernetesa P2 Cel: Optymalizacja środowiska wykonawczego dla z kubernetesem, HPA P3 Cel: Sam scoring I do tego dane. Poprzednie prace W literaturze łatwo znaleźć porównania wydajnościowe wielu frameworków 2, 3, 4, 7. 2, 3, 4 skupiają się na frameworkach PHP. 7 jest ogólnym zbiorem danych. Zmiana frameworka jest kosztowna i wymaga ingerencji w kod aplikacji bądź zupełnego przepisania. Brak natomiast źródeł, które sprawdzałyby wydajność aplikacji z wykorzystaniem różnych środowisk uruchomieniowych. Dla PHP będą to: Apache (mod-php), FPM, RoadRunner, PHP-PM, Swoole, FrankenPHP. Dla pythona można by sprawdzić np. uvicorna, gunicorna, pypy oraz cpythona w macierzy. Java nie mam pojęcia. Dotnet Kestrel vs http.sys.

Global Scrollbars look too boxy - but this you probably know ;) Selection box in the menu should have padding not margin, this would be consistent with how basically all other software behaves. Same thing goes for combobox selections. Tab header sometimes looses padding? Button hover effect should be subtle, now it stands out too much Tab Selector lacks hover effect Table headers focuses eyes way too much, it should be different shade of background color In case like "Custom Repositories" it even looks like there is one row which is selected: