파일 이름? 경로 이름? 기본 이름? 경로 조각의 이름 지정 표준
내가 사용하는 공통 명명 시스템이 없기 때문에 경로와 파일 이름을 조작 할 때 계속 매듭을 짓고 있습니다.
나는 명명 표준을 생각해 내고 그것을 준수해야하며 다른 사람들과 명확하고 일관성을 유지하기 위해 정식 답변을 배우기 위해 노력하고 있습니다.
이 장난감 문제를 고려하십시오 : (Windows 예제이지만 플랫폼 독립적이어야합니다)
C : \ users \ OddThinking \ Documents \ My Source 폴더의 전체 이름이 지정되었습니다. 폴더를 아래로 걸어 모든 .src를 .obj로 컴파일하십시오.
어느 시점에서 다음 문자열을보고 있습니다.
C:\users\OddThinking\Documents\My Source\Widget\foo.src
부품에 어떤 식별자 이름을 사용 하시겠습니까?
A) foo
B) foo.src
C) src
D) .src
E) C:\users\OddThinking\Documents\My Source\ - i.e. the top of the tree.
F) Widget\foo.src - i.e. the path from the top of the tree to the leaf.
G) Widget - i.e. one node of the tree.
H) C:\users\OddThinking\Documents\My Source\Widget\ - i.e. the name of the folder
I) C:\users\OddThinking\Documents\My Source\Widget\foo.src
시작하기 위해 몇 가지 답변을 드리겠습니다.
A) 기본 이름?
B) 파일 이름? 아니면 파일 이름입니까? 식별자 이름을 선택할 때 차이점이 중요하며 여기서는 일관성이 없습니다.
C) 확장
D) 확장. 잠깐, 그것이 내가 C라고 부르는 것입니다. 도트 저장을 피하고 필요할 때 입력해야합니까? 특정 파일에 점이 없으면 어떻게합니까?
H) 경로 이름? 아니면 그냥 경로입니까?
I) 파일 이름. 잠깐, 그것이 내가 C. Path라고 부르는 것입니다. 잠깐, 그것이 내가 H라고 부르는 것입니다. 아마도 H는 폴더 이름이어야합니다. 그러나 Windows 관련 용어 "폴더"가 아닙니까?
"표준"명명 규칙에 대한 검색은 헛된 것 같습니다. 다음은 잘 알려진 기존 프로그램을 기반으로 한 제안입니다.
A) C : \ users \ OddThinking \ Documents \ My Source \ Widget \ foo .src
Vim은 파일 루트 (: help filename-modifiers) 라고 부릅니다 .
B) C : \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src
C) C : \ users \ OddThinking \ Documents \ My Source \ Widget \ foo. src (점없이)
D) C : \ users \ OddThinking \ Documents \ My Source \ Widget \ foo .src (점 포함)
또한 파일 확장자 . 파일에 점이 없으면 확장자가없는 점없이 간단히 저장하십시오.
E) C : \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src
트리의 상단
규칙 없음, 자식은 기본 디렉토리 라고 부릅니다.
F) C : \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src
나무 꼭대기에서 잎
상대 경로 까지의 경로
G) C : \ users \ OddThinking \ Documents \ My Source \ 위젯 \ foo.src
트리의 하나의 노드는
규칙이 없으며 아마도 간단한 디렉토리
H) C : \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src
I) C : \ users \ OddThinking \ Documents \ My Source \ Widget \ foo.src
좋은 질문은 우선 +1입니다. Utility 클래스에서 한 번에 많은 함수를 만들어야 할 때이 문제가 발생했습니다. GetFileName? 또는 GetFullName? GetApplicationPath는 전체 경로 또는 디렉토리 이름을 의미합니까? 등등. 나는 .NET 배경에서 왔으므로 @blinry의 탁월한 대답에 조금 더 추가 할 수 있다고 생각합니다.
요약 : (이탤릭체는 프로그래머로 사용하지 않을 것입니다)
경로 : 경로는 파일 시스템에서 고유 한 위치를 지정합니다 (상대 경로가 아닌 경우). 경로 이름은 덜 자주 사용되지만 경로를 고수하려고합니다. 경로가 무엇인지 거의 설명합니다. 경로는 파일이나 폴더를 가리킬 수도 있고 아무것도 가리지 않을 수도 있습니다 (C : \). 경로는 다음과 같습니다.
- 상대 경로 :
My Source\Widget\
뿐만 아니라 상대 경로Widget\foo.src
입니다. 자기 설명. - 절대 경로 또는 전체 경로 : 대상을 가리키는 완전한 경로입니다. 나는 후자를 더 자주 사용하는 경향이 있습니다.
C:\users\OddThinking\Documents\My Source\Widget\foo.src
따라서 전체 경로입니다. 파일을 가리키고 디렉토리로 끝나는 전체 경로라고 부르는 것을 끝에서보십시오.
위키 페이지 및 .NET 명명 경로가 일치한다.
- 상대 경로 :
루트 경로 또는 루트 디렉토리 : 이전은 .NET 규칙이며 후자는 UNIX 서클에서 더 많이 들립니다. 나는 둘 다 좋아하지만 나는 전자를 더 사용하는 경향이 있습니다. Windows에서는 UNIX와 달리 각 파티션마다 하나씩 많은 다른 루트 경로가 있습니다. 유닉스 시스템에는 다른 디렉토리와 파일에 대한 정보를 보유하는 하나의 루트 디렉토리가 있습니다. 예 :
C:\
루트 경로입니다.폴더 또는 폴더 이름 :
Widget
,OddThinking
등 귀하의 경우. 이것은 Windows 전용 컨벤션 일 수 있지만 (실제로 내 자신의 이상한 생각 :)) 그럼에도 불구하고 나는 블링 리의 대답 "Directory"에 강력히 반대합니다. 일반 사용자 디렉토리를 의미하지만 같은 (하위 폴더, 하위 디렉토리 등) 폴더로, 나는 기술적 인 각도 "디렉토리가"대상이 아닌 대상 자체에 대한 자격을 갖춘 주소 같은 소리한다에서 생각합니다. 더 아래에.- 하위 폴더 : 관하여에
users
OddThinking
와Documents
하위 폴더입니다. - 하위 디렉토리 : 관련하여에
users
OddThinking\
,OddThinking\Documents\
및OddThinking\Documents\My Source\Widget\
하위 디렉토리입니다. 그러나 우리는 종종 그것에 대해 신경 쓸 필요가 없습니다. - 하위 폴더 :
users
OddThinking
하위 폴더뿐만 아니라 하위 폴더도 - 상위 폴더 : For
OddThinking
users
는 상위 폴더입니다 (단지 다른 용어를 언급하지만 별다른 의미는 없습니다).
- 하위 폴더 : 관하여에
디렉토리 또는 디렉토리 이름 : 전자는 일반적으로 실생활에서 사용하고 후자는 코드로 작성합니다. 이는 대상의 상위 폴더 까지 정규화 된 경로 (또는 단순히 전체 경로 )를 나타냅니다 . 귀하의 경우 (예, 디렉토리는 파일을 가리 키지 않습니다). 디렉토리는 .NET의 클래스이고 디렉토리 이름은 라이브러리 자체가 호출하는 것이므로 코드에서 디렉토리 이름을 사용합니다. UNIX 시스템에서 사용되는 dirname 과 상당히 일치 합니다.
C:\users\OddThinking\Documents\My Source\Widget
File Name or Basename: Name of the file along with extension. In your case:
foo.src
. I would say that for a non technical use I prefer file name (it is what it means for an end user) but for technical purposes I would strictly stick with basename. File Name is often used by MS, but I am surprised how they are not consistent not just in documentation but even in library. There filename could mean either basename or full path of the file. So I favour basename, that's what I call them in code. This page on wiki too says file name could mean either full path or the basename. Surprisingly even in .NET I can find the usage basename to mean the root name of the file.Extension or Filename Extension or File Extension: I like the last one. All refers to the same thing but what is it is again a matter of debate! Wiki says it is
src
while back then I remember reading that many of the languages interprets it as.src
. Note the dot. So once again my take is, for casual uses it doesn't matter what it is, but as a programmer I always see extension as.src
.Ok I might have tried to fetch some standard usages, but here are two of my conventions I follow. And it is about full paths.
I generally call a full path that point to a file as file path. To me file path is clear cut, it tells me what it is. Though with file name I find it as the name of the file, in my code I call it file name. It's also consistent with "directory name". From the technical side, name refers to the fully qualified name! Frustratingly .NET uses the term file name (so I have my case here) and sometimes file path for this.
I call a full path that ends as a directory a directory. In fact one can call any piece of address that doesn't point to a file a directory. So
C:\users\OddThinking\Documents\My Source\
is a directory,C:\users\OddThinking\
is a directory, or evenOddThinking\Documents\My Source\
(better to call it sub directory or even better relative path - all that depends on the context you are dealing with it). Well above I mentioned something different about directory which is directory name. Here is my take on it: I'll get a new path to avoid confusion. What is thisD:\Fruit\Apple\Pip\
? A directory. But if the question is what is the directory or even better directory name ofD:\Fruit\Apple\Pip\
, the answer isD:\Fruit\Apple\
. Hope its clear.
I would say it's better not to worry about the final two terms as that is what create the most confusion (for me personally). Just use the term full path!
To answer you:
with respect to the path you have given
A) No idea. Anyways I never needed to get that one alone.
B) basename
C) I would just call it file extension for time being, I am least worried since I never needed that alone to be named in my code.
D) file extension surely.
E) I do not think this is a general purpose requirement. No idea. In .NET base directory is the same as directory name.
F) relative path
G) folder (parent folder to basename
foo.src
)H) directory name
I) full path (or even file name)
in general (sorry for being a bit verbose, just to drive the point home) but assuming
foo.src
is indeed a fileA) NA
B) basename
C) NA
D) extension
E) directory or simply path
F) relative path
G) NA
H) directory or simply path
I) full path (or even file name)
Further driving with one example from my side:
Consider the path
C:\Documents and Settings\All Users\Application Data\s.sql
.C:\Documents and Settings\All Users\Application Data\s.sql
is the full path (which is a file name)C:\Documents and Settings\All Users\Application Data\
is the directory name.
Now consider the path
C:\Documents and Settings\All Users\Application Data
C:\Documents and Settings\All Users\Application Data
is the full path (which happens to be a directory)C:\Documents and Settings\All Users
is the directory name.
Two tips of mine:
I follow this rule of thumb that when it comes to addressing a full address irrespective of its type, I almost always call it "full path". This not only eliminates the use of two terminologies for file path and folder path, it also avoids the potential confusion if you are going to name that of file as file name (which for most users right away translates to basename). But yes if you have to be specific about the type of path, its better to name then file name or directory instead of more generic "path".
Whatever it is you would have your own idea in mind, be consistent with it throughout. Have a consensus among team members that this means this and not that.
Now that just from the circle I have some practice. A new brand of terms would be what is used on OS X and android machines. And all these are just about physical paths in filesystem. A whole new set of terminologies would arise in case of web addresses. I expect someone to fill the void in this same thread :) I would be glad to hear the convention with which you have went ahead..
In C++, Boost.Filesystem has devised a nomenclature for the various parts of a path. See the path decomposition reference documentation for details, as well as this tutorial.
Here's a summary based on the tutorial. For:
- Windows path:
c:\foo\bar\baa.txt
- Unix path:
/foo/bar/baa.txt
you get:
Part Windows Posix
-------------- --------------- ---------------
Root name c: <empty>
Root directory \ /
Root path c:\ /
Relative path foo\bar\baa.txt foo/bar/baa.txt
Parent path c:\foo\bar /foo/bar
Filename baa.txt baa.txt
Stem baa baa
Extension .txt .txt
C++ standard ISO/IEC 14882:2017
Moreover Boost.Filesystem terminology has been adopted by C++17 => See std::filesystem
Function name Meaning
---------------- -------------------------------
root_name() Root-name of the path
root_directory() Root directory of the path
root_path() Root path of the path
relative_path() Path relative to the root path
parent_path() Path of the parent path
filename() Path without base directory (basename)
stem() Filename without extension
extension() Component after last dot
No you're not crazy.
In Windows systems, sometimes the path of the directory containing the file is called path, which is how it was from the beginning. So, for example,
x:\dir1\dir2\myfile.txt
Windows:
--------
PATH: x:\dir1\dir2
FILE: myfile.txt
Unix/Linux:
-----------
PATH: /dir1/dir2/myfile.txt
FILE: myfile.txt
The Unix/Linux approach is a lot more logical, and that's what everyone mentioned above: path including the file name itself. However, if you type "call /?" in the Windows command line, you get this:
%~1 - expands %1 removing any surrounding quotes (")
%~f1 - expands %1 to a fully qualified path name
%~d1 - expands %1 to a drive letter only
%~p1 - expands %1 to a path only
%~n1 - expands %1 to a file name only
%~x1 - expands %1 to a file extension only
So there it is, "path only" and "file name only". At the same time, they refer to the whole string as "fully qualified path name" which is understood as drive letter plus path plus file name. So there's no real truth. It's futile. You've been betrayed.
Anyway,
To answer your question
This is how I'd name your examples:
A: -
B: basename
C: extension
D: -
E: -
F: -
G: -
H: pathname (or dirname or containing path)
I: full name
A-D-E-F have no simple nicknames. And since php is probably the most widely known cross-platform language, everyone understands "basename" and "dirname" so I'd stick with that naming. Full name is also obvious; full path would be a bit ambiguous but most of the time it means the very same thing.
Python's pathlib
standard library has a great naming convention for path components: https://docs.python.org/3/library/pathlib.html
a) C:\users\OddThinking\Documents\My Source\Widget\foo.src
stem
b) C:\users\OddThinking\Documents\My Source\Widget\foo.src
name
c) C:\users\OddThinking\Documents\My Source\Widget\foo.src (without dot)
[nothing]
d) C:\users\OddThinking\Documents\My Source\Widget\foo.src (with dot)
suffix
e) C:\users\OddThinking\Documents\My Source\Widget\foo.src
grand parent path
f) C:\users\OddThinking\Documents\My Source\Widget\foo.src
relative path to grand parent path
g) C:\users\OddThinking\Documents\My Source\Widget\foo.src
parent name
h) C:\users\OddThinking\Documents\My Source\Widget\foo.src
parent path
i) C:\users\OddThinking\Documents\My Source\Widget\foo.src
path
'Programming' 카테고리의 다른 글
PHP에서 비동기 HTTP 요청을 만드는 방법 (0) | 2020.05.08 |
---|---|
Java 8 스트림 : 다중 필터 및 복잡한 조건 (0) | 2020.05.08 |
TimeSpan을 XML로 직렬화하는 방법 (0) | 2020.05.08 |
AngularJS는 단일 페이지 애플리케이션 (SPA) 전용입니까? (0) | 2020.05.08 |
Java에서 가짜 웨이크 업이 실제로 발생합니까? (0) | 2020.05.08 |