Background: I am working with Angular (but my problem is not particular to any language or framework). In Angular, each component requires four separate files. So, we often find ourselves with 40+ files open. But, most of these files can be tiny, less than 20 lines each.
Many IDEs allow you to open your files in multiple windows. Each window can have a different panel, and each panel can have different tabs. This is great, but honestly, still isn't enough.
What I want: In addition to windows, panels, and tabs, I'd like to add another level of organization.
I speculate this has probably existed for decades, but I just don't know what it's called. At the very least, I speculate this has existed at least since Angular was a thing.
For example, here is a screenshot of VSCode with four files open across four panels. (Code taken from Angular dynamic component tutorial):
And here is a quick mockup showing what I'm looking for. Four files are open, but the three shortest ones are "concatenated" into one editor. Arrow-key down from the bottom of one file will bring you to the first line of the next file.
Notably, these files are not actually concatenated on-disk.
TLDR: What text editor can allow me to edit multiple files as if they were concatenated, as in the mockup above?
If the files stay as separate windows/tabs, the file editor would have to shrink each tab to a minimal height, and then tile them vertically. If any editor can do it, I suspect it would be emacs or vim. You might also be able to do it by opening separate editor windows and using a tiling window manager.
We can achieve a similar effect with some text editing magic. It would be something like:
Add a header to each file consisting of a unique separator (e.g. # === magic separator === filename my_file.js ===)
Use cat to combine all the files into one file
Edit this one file
When done, use the separator to break them up and put the text back into the original files
You could easily write some scripts for combining and splitting so you can do it quickly. You can also set up a background script that automatically runs the splitter as you edit the combined file. However, the combined file would essentially be a new file, so you could not view changes on it with git, and VS Code's CodeLens/Inline blame wouldn't work.
One option would be to develop your codebase with the combined files checked in to VCS, and then only have the splitter script as part of your "build" step. So you would make your changes, run ./build.sh which splits the files into some temp directory, and then run your application from there.
Lastly, and I hate to be snide, but the fact is that this problem is best solved by avoiding poorly designed frameworks that do not consider developer ergonomics. Many other languages give the developer much freedom and many tools to organize their code as they wish, rather than imposing constraints like requiring many small components to be in separate files. Java for example also had a similar problem (dunno if more recent versions fixed it) - you can only have one class per file, which creates a huge mess if you like having many small files. C# does not have this limitation and as a result C# codebases can be much tidier than Java codebases.
Related
I have seen Use a single source file for many QtDesigner forms, which is the gist of my question also, - but it simply recommends:
My advice is to use it as Qt way. Use seperate classes and seperate files for each form. This approach is better.
However, I would like to specifically know - is it possible at all to define multiple forms (say, a "Main Window" and a "Dialog with Buttons Bottom") in a single .ui file, and work with them in QtDesigner?
Basically, for an application of mine, I use QtDesigner .ui file to design the MainWindow, and load that from Python (PyQt5) - and it works great. Now, I'd just like to add a window dialog raised on a click of a button, and I'd also like to use QtDesigner for it, but I wouldn't want to maintain two .ui files. I'd imagine, once such an .ui file (with multiple form definitions) would be loaded in Python, the Python code would just set all forms other than QMainWindow to hidden, and then manage when they are shown appropriately.
(I use QtDesigner on and off, so I do not know it very well - however I recall there was some stuff that QtDesigner couldn't do from the UI, but one could do manually in the .ui file, and after such changes, QtDesigner could still deal with them. So, if there is a way to do this - even if it is not fully supported in the QtDesigner UI - I'd love to know about it, or have a definitive answer that it is not doable).
tl;dr
No, you cannot.
Why not?
UI files are intended for individual widgets (it doesn't matter whether they are intended as top level windows or not) and their possible children.
While I can understand your request, it seems more related to a "project" concept than an UI one. That's not the intent of Designer, which cannot imagine the possible extent of your project; and even if that was the case, it wouldn't be very practical: what if your project could potentially have hundreds of windows? Suppose that you have a main window, open your program, but then you decide to close it: your program would be loading hundreds of windows, but use none of them, causing an unnecessary overhead in the program loading.
The concept is similar to the modularization of OOP: not only you just "load" what you actually need, but you also should "split" the project in different files (modules, not unlike python modules) for better maintenance , reusability and overview. What if you want to have two separate "main" UI files for some reason, and, coincidentally, they use a similar dialog? You should copy that dialog every time, and if at some point you forget that step, you might even cause your program to crash as it's trying to access objects that don't exist or have been just slightly renamed.
Furthermore, some interfaces can be really complex, and automatically loading them at startup would be pointless: if you're using the uic module, you're requiring unnecessary parsing of the whole xml tree of the UI, and that would be for every time a new instance for a window from that file is required.
Maybe, someday, developers at Qt will decide to allow "projects" in Designer (which is probably what Qt Creator does, but I've never used it), but ui files will still be individual, as they should.
So, don't worry too much, it's more a question of habit and a slightly annoying aspect: if your project is well conceived, and you also properly name your files, it won't be a major problem and it will have its benefits anyway (even if you don't consider them as you could).
PS: yes, UI files are XML files and can be edited; you could even create/edit an UI file and do things Designer couldn't. But that's just an "unexpected feature" (or smart hack), for which you can never be always sure about the outcome. In future (or just different) versions the parser could be[come] more strict, with the result that your UI becomes completely unusable. That's not unlike editing pyuic files: the programs that use them expect a known behavior (the XML output of Designer), and common, accepted usage. As the recent pyuic file headers (which, I'd like to mark, was added after a personal suggestion of mine) report: "Do not edit this file unless you know what you are doing" ;-)
I'm trying to get a Cocoa development environment working in Emacs, and I'm 80% of the way there. The one feature I miss is Xcode's "Open Quickly", which basically performs a fuzzy match of the string you type against the filenames referenced in the Xcode workspace and the symbols defined in those files.
My problem is that our project is huge: if I generate a TAGS file using etags for the .h and .m files in our project's sub-directories, the result is over a gig in size and Emacs complains "TAGS file is large. Really open?", and if I say yes, then Emacs hangs and becomes essentially unusable. Of course, this is before I've even considered indexing tags for system libraries. I've also tried projectile, but unfortunately it's similarly unusable on a project of my size (on the order of a full minute to find a match).
It occurs to me that all the indexing information I really want is in the Xcode projects themselves, so if I had an Emacs package that could parse them and traverse their dependencies, that might be a start, but I'm not aware of any such package.
Any suggestions/solutions in this respect?
I've never found a single function quite as convenient as Xcode's "Open Quickly", but these days I use
helm-projectile-git-grep when I want to match on strings I know to be in the filenames, and
helm-git-grep for quick searches through the contents of the files themselves.
I've found that this gets me really close to what I wanted in my original question.
Some colleagues, now departed, had the habit of adding new classes within a related class file.
This makes refactoring painful.
Is there a tool, perhaps within XCode or AppCode or just a simple script, that will split up these monster files?
It appears there is a tool to help with this in AppCode, but it only semi-automates the process.
I'm using AppCode 2.0, I don't know if the same tool is available in AppCode 1.x.
To extract one class from a file to a new file, right-click the#interface or #implementation line and select Refactor > Move. Alternatively press F6 on that line. You can now enter a new file name, though you probably want to copy+paste the class name in here. At this point you can also select any defines you want to move.
I have done some work on a script to extract all classes in a file. I'd love to share this one day, when I get the chance to remove our clients code from the unit tests!
I don't think so there is any tool for this. However you can write your own osx application for doing the same.
The application will ask to browse the file, and it will search for #interface....#endand#implementation....~#end` and will create a file from this. If a single file contains two classes then it will result in for files (two headers and two implementation). Then the original file can be deleted manually or automatically.
I think this above task can be completed in few hours.
Here you can go for save the original file in a folder, just in case you want to rollback.
When your script gets to be thousands of lines long, finding a particular function or variable declaration gets to be a real pain. Are there any methods you can use to avoid this?
It really depends on the language and the editor you use.
If the language supports importing from external files, as most of them do, you should refactor your script into smaller modules and import/include them into your main script.
Also, most editors have some means of searching within a file and some, such as 'TextMate' (on Mac) or 'e', its Windows clone, provide a special view displaying all the symbols within the source which you can click on to immediately reorient the editor to the chosen target.
You split your code into separate files/modules/etc., generally organized by similar functionality, and require them in your main script.
I am still struggling to find a good naming convention for assets like images, js and css files used in my web projects.
So, my current would be:
CSS: style-{name}.css
examples: style-main.css, style-no_flash.css, style-print.css etc.
JS:
script-{name}.js
examples: script-main.js, script-nav.js etc.
Images: {imageType}-{name}.{imageExtension}
{imageType} is any of these
icon (e. g. question mark icon for help content)
img (e. g. a header image inserted via <img /> element)
button (e. g. a graphical submit button)
bg (image is used as a background image in css)
sprite (image is used as a background image in css and contains multiple "versions")
Example-names would be: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gif etc.
So, what do you think and what is your naming convention?
I've noticed a lot of frontend developers are moving away from css and js in favor of styles and scripts because there is generally other stuff in there, such as .less, .styl, and .sass as well as, for some, .coffee. Fact is, using specific technology selections in your choice of folder organization is a bad idea even if everyone does it. I'll continue to use the standard I see from these highly respected developers:
src/html
src/images
src/styles
src/styles/fonts
src/scripts
And their destination build equivalents, which are sometimes prefixed with dest depending on what they are building:
./
images
styles
styles/fonts
scripts
This allows those that want to put all files together (rather than breaking out a src directory) to keep that and keeps things clearly associated for those that do break out.
I actually go a bit futher and add
scripts/before
scripts/after
Which get smooshed into two main-before.min.js and main-after.min.js scripts, one for the header (with essential elements of normalize and modernizr that have to run early, for example) and after for last thing in the body since that javascript can wait. These are not intended for reading, much like Google's main page.
If there are scripts and style sheets that make sense to minify and leave linked alone because of a particular cache management approach that is taken care of in the build rules.
These days, if you are not using a build process of some kind, like gulp or grunt, you likely are not reaching most of the mobile-centric performance goals you should probably be considering.
I place CSS files in a folder css, Javascript in js, images in images, ... Add subfolders as you see fit. No need for any naming convention on the level of individual files.
/Assets/
/Css
/Images
/Javascript (or Script)
/Minified
/Source
Is the best structure I've seen and the one I prefer. With folders you don't really need to prefix your CSS etc. with descriptive names.
For large sites where css might define a lot of background images, a file naming convention for those assets comes in really handy for making changes later on.
For example:
[component].[function-description].[filetype]
footer.bkg-image.png
footer.copyright-gradient.png
We have also discussed adding in the element type, but im not sure how helpful that is and could possibly be misleading for future required changes:
[component].[element]-[function-description].[filetype]
footer.div-bkg-image.png
footer.p-copyright-gradient.png
You can name it like this:
/assets/css/ - For CSS files
/assets/font/ - For Font files. (Mostly you can just go to google fonts to search for usable fonts.)
/assets/images/ - For Images files.
/assets/scripts/ or /assets/js/ - For JavaScript files.
/assets/media/ - For video and misc. files.
You can also replace "assets" with "resource" or "files" folder name and keep the name of it's subfolders. Well having an order folder structure like this isn't very important the only important is you just have to arrange your files by it's format. like creating a folder "/css/" for CSS files or "/images/" for Image files.
First, I divide into folders: css, js, img.
Within css and js, I prefix files with the project name because your site may include js and css files which are components, this makes it clear where files are specific for your site, or relating to plugins.
css/mysite.main.css css/mysite.main.js
Other files might be like
js/jquery-1.6.1.js
js/jquery.validate.js
Finally images are divided by their use.
img/btn/submit.png a button
img/lgo/mysite-logo.png a logo
img/bkg/header.gif a background
img/dcl/top-left-widget.jpg a decal element
img/con/portait-of-something.jpg a content image
It's important to keep images organized since there can be over 100 and can easily get totally mixed together and confusingly-named.
I tend to avoid anything generic, such as what smdrager suggested. "mysite.main.css" doesn't mean anything at all.
What is "mysite"?? This one I'm working on? If so then obvious really, but it already has me thinking what it might be and if it is this obvious!
What is "Main"? The word "Main" has no definition outside the coders knowledge of what is within that css file.
While ok in certain scenarios, avoid names like "top" or "left" too: "top-nav.css" or "top-main-logo.png".
You might end up wanting to use the same thing elsewhere, and putting an image in a footer or within the main page content called "top-banner.png" is very confusing!
I don't see any issue with having a good number of stylesheets to allow for a decent naming convention to portray what css is within the given file.
How many depends entirely on the size of the site and what it's function(s) are, and how many different blocks are on the site.
I don't think you need to state "CSS" or "STYLE" in the css filenames at all, as the fact it's in "css" or "styles" folder and has an extension of .css and mainly as these files are only ever called in the <head> area, I know pretty clearly what they are.
That said, I do this with library, JS and config (etc) files. eg libSomeLibrary.php, or JSSomeScript.php. As PHP and JS files are included or used in various areas within other files, and having info of what the file's main purpose is within the name is useful.
eg: Seeing the filename require('libContactFormValidation.php'); is useful. I know it's a library file (lib) and from the name what it does.
For image folders, I usually have images/content-images/ and images/style-images/. I don't think there needs to be any further separation, but again it depends on the project.
Then each image will be named accordingly to what it is, and again I don't think there's any need for defining the file is an image within the file name. Sizes can be useful, especially for when images have different sizes.
site-logo-150x150.png
site-logo-35x35.png
shop-checkout-button-40x40.png
shop-remove-item-20x20.png
etc
A good rule to follow is: if a new developer came to the files, would they sit scratching their head for hours, or would they likely understand what things do and only need a little time researching (which is unavoidable)?
As anything like this, however, one of the most important rules to follow is simply constancy!
Make sure you follow the same logic and patterns thoughout all your naming conventions!
From simple css file names, to PHP library files to database table and column names.
This is an old question, but still valid.
My current recommendation is to go with something in this lines:
assets (or assets-web or assets-www); this one is intended for static content used by the client (browser)
data; some xml files and other stuff
fonts
images
media
styles
scripts
lib (or 3rd-party); this one is intended for code you don't make or modify, the libraries as you get them
lib-modded (or 3rd-party-modified); this one is intended for code you weren't expected to modify, but had to, like applying a workaround/fix in the meantime the library provider releases it
inc (or assets-server or assets-local); this one is intended for content used server side, not to be used by the client, like libraries in languages like PHP or server scripts, like bash files
fonts
lib
lib-modded
I marked in bold the usual ones, the others are not usual content.
The reason for the main division, is in the future you can decide to server the web assets from a CDN or restrict client access to server assets, for security reasons.
Inside the lib directories i use to be descriptive about the libraries, for example
lib
jquery.com
jQuery
vX.Y.Z
github
[path]
[library/project name]
vX.Y.Z (version)
so you can replace the library with a new one, without breaking the code, also allowing future code maintainers, including yourself, to find the library and update it or get support.
Also, feel free to organize the content inside according to its usage, so images/logos and images/icons are expected directories in some projects.
As a side note, the assets name is meaningful, not only meaning we have resources in there, but meaning the resources in there must be of value for the project and not dead weight.
The BBC have tons of standards relating web development.
Their standard is fairly simple for CSS files:
http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml
You might be able to find something useful on their main site:
http://www.bbc.co.uk/guidelines/futuremedia/