What are the unwritten rules for organizing layout?

Question

PHP

Interested specifically file organization, file naming.
Here, for example, I ran into a philosophical problem, where is it better to put SASS files?)
In general, we need an example of the file organization of a canonical project.

Answer 1

Something like this
here sources
src
- sass
--- header
----- header.sass
--- footer
----- footer.sass
--- body
----- body.sass
--- style.sass
- js
--- jssrc
generated files here
target
- style.css
- app.js

Answer 2

Basic layout principles
copist.ru/blog/2015/08/29/web-layout-basics

Answer 3

You can put Sass in the CSS folder, or create a Sass folder in Css
And it should be like this:
/img - all images
/css - files with design
here /libs - js plugins here (sliders, animations, bootstrap, etc.)
/ js - here you can put a js file where the parameters of these plugins will be specified (common.js)
Personally, I have Sass in the CSS folder because Koala for some reason duplicates the files where the Sass files are located and where I specified the compilation i.e. in / css , it turns out porridge, so I throw all css, sass files into one folder / css and everything is fine, but of course it’s better to create a Sass folder in CSS if there is no such problem. In general, there really is no difference, do it as it is convenient, the main thing is that you understand what and where lies.
And yet, in Brackets, for example, when working in Sass, links to images are not filled in, for example, when you write in src = "" - img, i.e. you start filling in src, then the editor usually suggests the paths to the files, and if sass is not in the same folder as CSS, the paths will be different and you need to write it manually because it will no longer be ../fonts/ but it will already be ../../fonts because the Sass folder will not lie where the CSS file is compiled, but inside i.e. / css /sass

Answer 4

Now I’m switching to project assemblers and I can say so, only thanks to them I realized the beauty of project modularity. Very convenient, useful, etc. Especially when you make templates for, say, a specific system (cms, framework assembly, etc.), you throw modular pieces of code along with styles defined by html and js.
app/
-bower_components
-/less
--main.less
-/js
--main.js
-/img
--/icons
-/fonts
-/tpl
--this approach allows me to move the styling of various blocks from project to project.
--/header
---*.html
---*.js
---*.less
--/footer
---*.html
---*.js
---*.less
--...
--/search
---*.html
---*.js
---*.less -index.html
-...
-inner
-page.html
dev/
we reduce scripts, etc. We just work, since compression, etc. sometimes slows down the process.
build/
- here after the end of a certain stage of the sprint, etc. We throw the compressed version for production.
This method clearly reflects where you need to go to fix this or that module. But I think this is not for everyone, there are specific projects. There we sharpen for the project :)

Answer 5

Here - sass-guidelin.es/en/#section-52