Does the name of a directory title 'the container' or the 'contents'? This question nags at me because if the name of a directory semantically titles 'the container' then the name should be singular. (By analogy: When referring to an actual physical bag that contains your groceries - one would probably refer to it as a 'grocery' bag and not the 'groceries' bag.) Conversely if one were to assert that the name of the directory titles the contents of the directory then it would make more sense to use a plural form.
I understand that there are common-sense and even usability concerns associated with this question; however, although I would like to hear the practical results of these two options I am more concerned with semantics.
So in summary: does the name of a directory serve as a title for the container or the contents?
Thanks.
A directory on its own needs no name as a directory without any content is useless. Directories exist to group a set of files together. Even if a directory is currently empty, it represents such a group, just that there are currently no files in this group and that's why it is empty. So the name of a directory should always describe what you can find within that directory.
Assume you have a drawer with boxes and you use these boxes to group physical objects together. To know what is inside each box without having to first open it and look inside, you label the boxes. How would you label these boxes?
If a box contains pencils, you'd label it Pencils and not Pencil, correct? If a box contains paper clips, you'd label it Paper Clips and not Paper Clip, wouldn't you? That's because in these cases the label only describes the kind of item to be found within the box. Same goes for directories. A directories containing pictures should most likely be named Pictures, so you know that the files you can find inside it are of type picture.
But sometimes you group items together, not because they are of the same kind but because they belong to the same "entity". E.g. if you have a large box that contains all items related to your trip to Japan in 2012, you would label it "Trip to Japan, 2012" or maybe just "Japan, 2012". Actually you could label it "Trip to Japan in 2012 Items" but "Items" is redundant, as it is obvious you will find items inside. The same way it is redundant to add "Files" to a directory name. So if you are not grouping files because the files itself have something in common but because they belong to a common "entity", you usually name the directory after that entity and since is only one such entity, it would be singular.
A directory with the pictures of Peter's Birthday would most likely be named Pictures/Peter's Birthday. On the other hand, if you keep pictures of every birthday of Peter, year after year, you would rather use a structure like Pictures/Peter's Birthdays/2016. Note how it suddenly became "Birthdays" as now the directory name again describes the kind of items found inside and not an individual event/purpose.
As a general rule of the thumb: Always name directories in such a way that the reader of the directory name has a very good idea of what kind of files and other directories they can expect to find inside that directory, so they can decide whether it's interesting to "go there" or not by just having read the directory name.
If you name a directory Recipe, what will the reader expect to find inside? I would expect to find one or more files, all belonging to a single recipe, e.g. a short ingredient list, a longer instruction text and maybe some supporting photos. Contrary, if you name the directory Recipes, what will the reader expect to find there? I would expect several recipes, either multiple files and every file contains one recipe or multiple sub-directories and each one contains the files that belong to one recipe. As you can clearly see by this simple example, whether you choose plural or not has an effect on the expectation of the reader.
My first impulse is to say that you name a generic container based on its contents. But I'll dig a little deeper just for the fun of it. (Scroll to the end if you just want the summarised conclusion.)
Firstly, I don't think Tum's car and cake examples help us very much. Sure, they are made from simpler components, but only for the purpose of creating new and self-contained objects. The grocery bag is a collection of molecules—so what. The more meaningful thing to ask is: is the object's fundamental purpose to hold other objects? In other words, is it a generic container, like the folder in a file system? You would definitely answer no to the cake. You would probably answer no to the car (even though it does, admittedly, hold people). You would certainly answer yes to the grocery bag.
In your grocery bag example, you said we would refer to it as a grocery bag and not the groceries bag. Sure. The following sentences are all grammatically correct and natural sounding:
Would you help me bring the bags in?
Would you help me bring the grocery bags in?
Would you help me bring the groceries in?
Would you help me bring the shopping in?’
The first sentence is only meaningful if the listener knows we just went shopping and can infer the contents of said bags without us telling them. Without that information, the bags might, for all we know, contain venomous snakes. The second sentence is the most descriptive, but includes redundant information. Anyone familiar with groceries and the process of buying them can reasonably infer that they will be contained in bags. The third sentence tells us all we need to know in the most succinct manner.
The forth sentence takes a different approach entirely, labelling the singular activity that produced the groceries. But it doesn't tell us what kind of product we shopped for, so it’s not as descriptive. (Sometimes this approach is the best option as will be seen in other examples.)
If you look at the user's home folder on any new Windows PC or Mac, you'll find it pre-populated with folders like Documents, Downloads, and Pictures. A folder labelled 'Pictures' tells us all we need to know. You could choose to suffix all your directory names with 'dir', 'folder' or something similarly redundant, but it adds nothing meaningful. (I'm old enough to remember seeing Mac users of yesteryear add the 'ƒ' character—generated by pressing Option-F—to the end of folder names. Crazy times.)
Ah, but there are exceptions! On my Mac, Apple (in its infinite wisdom, of course) chose singular names for three subfolders: Desktop, Library and Public. The rationale, one suspects, is that no one knows what the Desktop contains—not even the user oftentimes! Similarly, the Public folder might contain anything. To get all scholarly, we would call it a heterogeneous collection. It’s like that big box of stuff you pull out at Christmas time, which contains a hotchpotch of stuff like tinsel, baubles, stockings, wrapping paper and fake snow—easier to just label it ‘Christmas’, according to its purpose and theme.
The Library folder is an interesting one—not so much because Apple didn't name it according to its contents, but because it gives us an interesting real-world example. Is the purpose of a library to hold other objects, or is it a functional object in its own right? I'd say it's somewhere in the middle. Let’s say we decide to label a real-world library based on contents. We could call it ‘Books’. (Most libraries contain more than books, but to keep it simple we'll imagine that our library only contains books.) A library could hang a big sign out front that just said 'Books'—but then you might assume the books were for sale, rather than free to borrow. You'd probably assume this because you live in a capitalist society where most big signs are trying to peddle something. So the question of semantics is also one of context.
There's one more question of context that you didn't supply in your question. Where are these directories stored? Are they on your personal computer, or are they on a web server? Why does it matter? Well, on your PC, you're probably viewing each folder in a GUI, where the label is attached to an individual icon. But if the directories are part of a website structure, it's more likely that users will only ever see the names as part of a file path (if they notice them at all). The question here is, do you care, and if so, do you want the file path to read like a sentence? This is best illustrated by an example:
http://acme.com/order/explosive/detonator/dx3000
While each category could be plural, the path reads more like an English sentence by using singular directory names. While this seems a bit forced perhaps, you do see this approach on some websites.
TL;DR: When the function or theme of a container is more descriptive than its contents, a singular label (e.g. Library, Desktop, Christmas) can work best. The more heterogeneous a collection, the more likely this approach will make sense. But in most cases, labelling the plural contents (e.g. Documents, Downloads, Pictures) of the collection is easier and more descriptive.
Interesting question.
If you look at a class as a substitute for a tag name (something you would do when using a <div> or a <span>, which have no semantic meaning), your class would have to describe the contents of the element.
But at the same time, the element it self is the content. If you look at a car you say 'this is a car', you don't say 'these are car parts'. Or, if you eat a cake you call it 'cake' and not 'ingredients'.
So I guess a semantic class name would be singular and not plural, because it is always only one element. This might result in using a lot of 'wrapper' in your class names, because finding a fitting name for your element is not always that easy.
I hope this answers your question, if not you might want to read this: http://css-tricks.com/semantic-class-names/
The convention proposed by user Mecki is coherent, but I wonder whether it is really useful in the context of file organization.
In my experience, a very useful convention is to see file path components as a collection of searchable tags. This aids in classifying and finding files, which, for me is the main purpose of establishing a convention for directory and file names.
For example, one file could be named camera-MODEL-manual.pdf (where MODEL is the concrete model). There could be also a directory that contains various manuals. Or perhaps there are multiple manuals for a particular device. In that case, they could be kept in manual/DEVICE/.... Naming directories that contain manuals with the tag "manual" in singular helps searches for manuals.
Within this convention, one can search for file paths containing "birthday" and "peter" without having to remember whether the directory is "2022-birthday-peter" or "birthday/peter/2022". Or one can search for all PDF files whose path contains "car" to find some car-related document.
While in English most plural forms are simply created by adding an "s" suffix, so that a search for "birthday" may bring up "birthdays", this is not true in many other languages. And even in English, it may be preferable to search for whole words, such that a search for "birth" does not bring up "brithday".
Related
TL/DR: I have a game plan on how to do this below; however, I am wondering if my plan is going to prove to be too complicated, and what additional considerations I need to take into account before diving into building this project. Although I am not an experienced programmer, I am NOT asking for code; I am asking for feedback from experienced Word VBA programmers as to whether my entire idea/approach is one huge mistake.
I have a document "template" (not yet a template file type - I hope to create that as described below) for a report. The report is broken up into different sections:
Letter to the Client
Table of Contents
Section I
Title Page
Body
1.0
2.0
Section II
Title Page
Body
1.0
2.0
Appendix A
Title Page
Body
Appendix B
Title Page
Body
I want each major "metasection" (such as Letter, Section I, Section II, Appendices) to have different styling and formatting. This could be accomplished by having multiple styles for each metasection, e.g.:
Normal-Letter
Normal-SectionI
Normal-Appendices
Heading1-Letter
Heading1-SectionI
Heading1-Appendices
This would quickly become unmanageable.
In order to avoid users having to wade through a huge number of styles to find the correct one (and it is worth noting that if users of this report have to do this, they will likely not use styles AT ALL), it would be nice if I could have the same style name (e.g, Normal) be different depending on which section of the document it is found in. Or said another way, I would like for a document to have multiple style sets depending on the section.
The goals for the user experience are:
The user simply applies the Normal style, Heading1 style, etc, as necessary.
Registered section-specific style definitions are updated when styles are edited via the Modify Style dialog box, or other ways.
The styles are applied automatically and transparently when styles are changed, or when the document is opened, saved, or printed.
ALTERNATIVE: If automatic/transparent style application proves too difficult, execute the style-application routine with a simple command button.
My initial idea on how I might do this in VBA is:
Write VBA code (probably a class) such that there is a style registry of Normals and Heading1s, etc., for each document section.
Write a style-application subroutine which iterates through the registered document sections, selects all the parts with each registered style, and applies the section-specific style from the style registry (preserving any styling that deviates from the style definition).
Write a style-update subroutine that automatically and transparently updates the registered style definitions
The style-application subroutine executes any time styling is applied anywhere in one of the registered sections (so I'll need to tie into Events here).
The style-update subroutine executes any time a style definition in a registered section is changed (so here's another Event I'll need to monitor).
I previously asked a similar question about this topic on Superuser. The feedback I received has led me to believe that I can only accomplish the behavior I want using VBA, so I am now asking a follow-up question here on Stackoverflow.
My question is: am I making a mistake here? I have a feeling there is a better way to solve this problem (perhaps using VBA, perhaps not) than this.
Yes, in my opinion, you are making a mistake.
I have just recently finished a project where I have created a document template for a company. My experiences:
Users vary in knowledge level (obviously)
High level users don't like over-engineered files, because they can't use their own macros as they might conflict with the file's own macros, they can't use their doc properties or their own building blocks etc., as these likely won't be compatible with the macros (or at least they think they won't work, and fiddle around until they actually manage to break them)
low level users are intimidated by the automatisms, and keep avoiding them as long as they can (which means as long as their bosses don't order them to use the file), after which point they start hating the file and the work
Complex solutions like this one usually get abandoned after a few years. Eg. the original developer changes jobs, or moves to another department, and nobody understands the code enough to keep managing it (especially if it is not a well-documented, well-written code, which it won't be, as you are not an experienced VBA programmer).
The developer (you) will be inundated with (sometimes false) bug reports and questions and minor change requests, which gets really annoying after a few weeks (trust me on that :) ). They won't dare change even a font size without consulting you, and in the end, they will ask you to do it. Or, even worse, they try to change something, break it, and then tell you to fix your bug.
Your users would have to remember to use section brakes or other kinds of indicators to indicate the next section. This will seem too much for some, too complex, and if they accidentally remove a section indicator (which they inevitably will), all hell brakes lose, and worst of all:
Undo function will be disabled after each macro run. This, to most users, is a disaster. You don't do that to your users.
So I would say don't go down the macro route. Don't use Doc properties, that didn't work at the company I was working with. (Actually an IT company, with mostly high-level users :) ) The high-level users will create and use their own doc properties, for others, it is just a hassle. Bookmarks get constantly deleted, so no-go either.
My advice:
Use styles. Users will learn to use them quickly.
Get a decent document design. Having 4 different sets of title, heading and normal styles in one document is really unprofessional. Consistency is important, especially as this seems to be a letter to you clients. (Yes, I know, your company is different and your bosses are dumb and this is a special case and and and ... Just saying, talk to a designer, and get a professional look for your template.)
You can manage the Style gallery (Home tab, centre) drop down list on a template basis - so your template will load the used styles into the dropdown at the top, and remove everything else. This works really good, and even as much as 20 styles is manageable, if they are well-named.
Use building blocks: title pages, tables, pre-written and formatted Quick parts (legal mumbo-jumbo, company introduction, contacts, etc.), headers and footers...
And, if you want happy-happy and cooperative users:
After creating a blank template, create a full template:
Fill up a document template with texts, pre-written paragraphs, pre-written titles, so they will only have to click and rewrite, without the need to format or bother with styles and Cover pages and the lot
Educate the users: 2 sessions of 1,5 hour Word class can go a long way. It is a must.
Long post. One last thing: creating a complex Word template, you will be sailing a sea of Word bugs and annoyances. Even without writing macros, this won't be a walk in the park. (I for example gave up on making my TOC work in Office 2013, as after 3 days and 10 versions, it still kept on creating a maximum sized extra paragraph whenever it was inserted. Only in W2013. Still no idea why, but I let it go.)
Whatever you decide to do, best of luck, and have a lot of patience! :)
So i have developed an application in vb.net but recently i came across the requisite of allowing multiple languages for it. I dont know if there is any 'common' way of doing this kind of things, but my approach to accomplish that is the following:
I'll need to search in the code for components, error messages and everything that is displayed in the GUI of the application to be translated.
Secondly i will create a class in which i'll store in memory a dictionary of everything that will be translated
after, i'll replace the stuff to be translated withing an entry of the dictionary
then when the application start i'll load the dictionary
later on, i'll replace the static dictionary and will load it in memory from the database
So for example, my dictionary class:
Dim dictionary As New Dictionary(Of String, String)
dictionary.Add("00011", "hello there!")
Somewhere in my code i'll replace:
mylabel.text = "hello there!"
With:
mylabel.text = dictionary.item("00011")
Later on i will, instead of having a static dictionary, create that dictionary getting the information from a database like this (and load it at the start of the application:
_______________________________________
word_code ### word_EN ### word_FR
_______________________________________
00011 ### hello there ### bonjour il
I will load the dictionary considering which language is selected.
I'm not very confortable with this approach and i have no idea if this is the right thing to do, but if so i have a couple of questions:
is a dictionary the best data-structure to do so?
will this be memory-heavy considering i'll have 1000 entries, 1m entries or 10m entries?
is there any logic and faster way of accomplish the same?
Thank you so much in advanced,
J
It's a common way of doing it - having a system name along side a language code being used to look up a translated value. However, generally speaking I'd only advice you to do this for something like system texts and smaller text segments.
The reason is that in for example CMS/ecommerce systems, pages with lots of text likely will need to be translated in a data model to support it to begin with; and then you already have the language division.
So in that situation, you're better off making a page structure with a translated data model where the detail will be language specific per language for your current website.
For example, you'll have a product -> product_detail where detail keeps the translated values for said product. Similar for article -> article_detail and so on.
But for general translations and system texts which needs to be displayed, it's a common way to do it.
And as you suggest yourself, structures like like dictionary would be a good structures to to make fast look ups and can be cached in the system so you do not need to retrieve them all the time.
Some ways you can expand on it, is by sub dividing your translations into sub groups; say you have an order page and a product page. Then you can have translations assigned to "product" and to "order" with a "common" group as well.
It will also make it easier to build smaller cache objects, extract less data from your data storage etc, so a page which only revolves around orders don't need to worry about product translations.
It will require memory, but unless you put entire CMS systems into the translations, it should be "minor".
I would however question a need of 10 million entities of translations and wonder whether or not your system actually requires that many and if it does, then maybe consider an alternate approach and whether it might be better to make multiple versions of the "page" to eliminate the need for translations.
I would also advice you to not use "00011" as a system code to begin, and go for a more "readable" version (like "hello") to ease the readability and maintainability of your code. Then if you want a 'system value' which is like "00011", it's easy to do a search/replace.
I am using some of the subVIs that other people wrote so this is some historical issue.
The problem I have is that if two different subVIs are different, stored in different locations, but happens to have the same name.
It seems sometimes LabVIEW confuses the two of them and the link jump from one to the other, since the two subVIs are different, this makes errors.
So my question is: is this something real? That LabVIEW call subVIs by their filename rather than absolute filepath. Or am I describing something unreal and may be caused by other issues.
Thanks!
There are two separate things here. The first is that LV remembers where each file that something uses is placed, and there are three ways it can store that path (assuming I'm not forgetting any):
Logical. These are folders like vi.lib, where the base folder is represent by a name (so the path is stored as "|vilib|\...\myVI.vi"). This allows you to call the correct file when you go to a different LV version.
Relative. This is how LV normally saves paths, so if VI A calls VI B and they're in the same folder, the path to B inside A will be stored as "..\B.vi".
Absolute. I believe this is only reserved for VIs which are stored in a different volume, but do not match the first rule.
If for whatever reason LV doesn't find the file where it's supposed to be, it will take the one already in memory or try to search for it in other places, at which point you get a searching dialog.
The second thing is that there can only be one VI with a specific name in memory at any one time. If you load two VIs with the same name, you will get a conflict and have to resolve it, as you've seen. This isn't LV getting confused, just a matter of each calling VI referencing another VI with the same name and the order in which you load them. Technically, I suppose that LV could have used the full paths to allow duplicate names, but I believe that this decision goes back at least 20 years, so it won't be changed now, and it certainly would be a problem when you consider that now you can reference VIs in memory by name. It also has some other technical merits.
If you do have VIs which need to have the same name, what you will most likely want to do is namespace them. In the past, this was often done by actually changing the name using a prefix or a suffix. These days, you would usually do this by placing the VI in a library (such as .lvlib or .lvclass). This doesn't modify the file name, but it does become part of its fully qualified name, which is what determines collision, so it allows you to have multiple VIs with the same name. In the case of classes, this is actually a requirement, as that's the mechanism used to determine which VIs will override.
I am creating an object oriented representation of a novel or book. I am looking for design patterns or advice in terms of what to make an object, and what to make an attribute of another object.
For example, suppose I'm interested in the characters in the novel, and which chapters and pages they appear on.
The concept I'm struggling with is how to organize an object system with two types of "containers" that both participate in relationships with the same instances. I imagine this comes up in other systems where there is a metaphorical "physical" and a "logical" view of the underlying data.
There are a variety possible objects here: Novel, Chapter, Page, Character.
There are a variety of relationships between these possible objects:
Novels have a sequence of Chapters, a sequence of Pages, and a collection of Characters
Chapters have a sequence of Pages, and a collection of zero or more Characters
Pages are associated with one or more Chapters, and zero or more Characters
Characters are associated with one or more Pages and Chapters
The purpose of these objects would be to answer questions like:
What pages does character Alice appear on?
What characters appear in chapter 6?
Which characters frequently appear on the same pages?
What page is character Bob mentioned for the first time on?
I'm a bit lost as to how to approach this sort of design. I see a few approaches:
Make everything (Novel, Chapter, Page, Character) an object, and each of these objects has lists of references to other objects they contain / relate to
Give primacy to one or the other of Chapter or Page, and make the other an attribute of the first. For example we could go with just a Novel, Chapter, and Character object list, and make "pages" an attribute of the Chapter object.
We could take the above idea even further and just stick with Novel and Character, and give each Character a few attributes such as: "Occurs in Chapter" and "Occurs on Pages"
Well, I hope that's clear enough for some OO design gurus to suggest where to draw the line between Object or Attribute, and how to design an object system where there are different kinds of containers (Chapter, Page) that the objects of interest (Character) belong to.
It is important that you have stated the purpose of your software will be to answer various questions about the book, including what characters appear on a given page.
This tells us two things:
You are seeking to model the physical layout of a particular
edition of a book (since other wise the example question above would
make no sense).
Your design is going to be heavily influenced by
the scope of the questions that need to be answered, as this will
determine whether your system will:
use data structures to pre-cache meta-data that will be required as answers (e.g.
explicitly store a list of pages a character appears on),
store the "raw data" (e.g. as a tree of novel > chapters > pages > text) which is then processed to answer a given question,
some combination of both
I suspect that a combination is likely to be right in your case, so your "raw data" will be represented in similar fashion to the first approach you mention:
Make everything (Novel, Chapter, Page, Character) an object, and each
of these objects has lists of references to other objects they contain
/ relate to"
except that instances of Page would reference instances of Text, rather than Character which instead would become a meta-data class.
Meta-data could be pre-cached, or generated on demand by trawling the raw data.
Either way, you'll want to normalize your data model,
Files and directories could have different namespaces, and still be used to identify specific files, because a file and directory with the same name can be distinguished by being different kinds of things.
Primitive field and reference fields could also have different namespaces (in Java), because if a primitive and a reference field had the same name, they could be identified by being different kinds of things.
Separate namespaces are used elsewhere like this. For example, in Java, you can have a method exampleName() and a field exampleName, and though they have the same name, they are distinguished by being different kinds of things.
First, this question is language specific. In pure OOP languages there's no distinction between atomic and compound elements. Everything is an object. By a similar reason in a pure functional language you can't have function and variable named the same.
Second, if you have polymorphic operations, there's no way to tell which variable did you refer to. For example, you can't have different namespaces for files and directories, because of the polymorphic operations, like
cp foo bar
The cp works on files and dirs, and if you have different namespaces, there's no way to tell what did you mean.
I do not believe that this would be a good idea. I imagine that the reasons involve things like performance and simplicity of the filesystem code. If a directory listing had to go down 2 or 3 or more different paths depending on how many different namespaces you think you should have, this would probably complicate the code.
Additionally, consider the end user confusion that might arise. Currently we have a kind of namespacing available in filesystems by using file extensions. You can have file.txt and file.dll and file.exe all existant in the same directory. What happens when these files are present simultaneously is a matter of concern - this has been one method for virus writers to use a form of social engineering to get you to click on the wrong file. Imagine if you could confuse a directory with a file of the same name as well?
Directories and files aren't necessarily so different. They are both entries in their parent directory, just with a flag to indicate if an entry is a directory or not. You can open a directory and read it just as if it was a file, just that certain other operations are possible on it- symbolic links work the same way. (This description is biased towards the Unix filesystem view, but I think the DOS/Windows view works much the same way). Within any directory, there is a set of names of members, and the filesystem enforces the uniqueness constraint that a directory can only have one member with a given name.
Thinking about Java method names compared to field names--- back in C, you couldn't have a global function and global variable with the same name, because all the symbols in the object file are in a single namespace. But you could with C++, because a function "void foo()" was mapped to mangled symbol name ("foo__vv" or something). So it's not so much that they have a separate namespace, as that the key into the namespace is different for a field "foo" vs a method "foo()". Given that you can't get key clashes, they look like separate namespaces, but is that really how it's implemented?