Python thụt lề tab

Question

Kiểu mã hóa (kiểu lập trình) là bộ quy tắc hoặc hướng dẫn được sử dụng bởi các thành viên lập trình khi viết mã nguồn phần mềm. Các thành viên lập trình thường được yêu cầu theo dõi các quy tắc này để đảm bảo tính dễ đọc và dễ hiểu của mã nguồn, phòng tránh lỗi tiềm ẩn. Bởi vì vòng đời của một phần mềm, thường quá trình duy trì nhiều hơn là quá trình viết mã. Nên đọc, hiểu mã nguồn là rất quan trọng

Nội dung chính Show

chiều dài dòng. tại sao luôn là 80?
Ngược dòng lịch sử
Một số quy ước khác về độ dài dòng
thụt đầu dòng. tab so với. không gian
Khi nào thì việc sử dụng tab trở thành vấn đề?
Trình chỉnh sửa xử lý thụt lề như thế nào
Do that end. tab hay không gian?
thụt đầu dòng. 2 so với. 4 so với. số 8
giai đoạn kết thúc câu. 1 không gian vs. 2 dấu cách

Tuy nhiên, rất nhiều quy ước đặt ra được các thành viên lập trình chấp nhận, nhưng không hiểu lý do tại sao. Bài viết này sẽ tìm hiểu một số quy ước như vậy

chiều dài dòng. tại sao luôn là 80?

Một quy ước được áp dụng vô cùng rộng rãi, đó là giới hạn số ký tự trên mỗi dòng không quá 80 ký tự. Tôi đã làm việc với rất nhiều phong cách mã hóa khác nhau, nhưng về cơ bản, số ký tự trên mỗi dòng luôn được giới hạn là 80. Riêng PEP 8 của Python thì. 79 hay 80 cũng không khác nhau nhiều lắm. Tuy nhiên, rất lạ khi tôi thấy ai đó đưa ra quy tắc này mà giải thích về nó. Tại sao lại là 80, mà không phải 100, hay lớn hơn nữa

Thỉnh thoảng cũng có người thích thú, đại ý rằng 80 ký tự sẽ giúp người lập trình viên nhìn được toàn bộ code với màn hình nhỏ. Với màn hình lớn, họ có thể nhìn 2 tệp song song với nhau mà không có phần mã nào bị che khuất. Ngoài ra 80 ký tự cũng làm việc tốt với mã đánh giá của các công cụ

Theo tôi, lý do này thật không thuyết phục chút nào. Các công cụ để lưu trữ và xem lại mã như Github và Bitbucket cho phép hiển thị một dòng dài hơn nhiều. Bitbucket could show long line to 130 characters. Github could show long line 125 character (ngày trước là 119). Hay việc xem code trên máy cá nhân cũng vậy. Màn hình máy tính xách tay của tôi thuộc về nhỏ cũng hiển thị được hơn dòng hơn 100 ký tự. Màn hình lớn hơn, khi chia đôi vẫn có thể hiển thị dòng gần 100 ký tự. Vì vậy, lý do giới hạn số ký tự trên một dòng là 80 để có thể thấy toàn bộ mã không hợp lý nhìn cho lắm

Sau khi tìm hiểu, tôi mới biết rằng, giới hạn 80 ký tự này có nguồn gốc từ đâu

Ngược dòng lịch sử

Sự cố của IBM được phát hiện vào năm 1928 bởi Herman Hollerith và nó có 80 cột. Đặt ra một câu hỏi là. at sao sheet này lại có 80 cột. Tấm trải này được thiết kế dựa trên kích thước của đồng tiền vào thời điểm năm 1880 (lúc đó nó hơn bây giờ), và Hollerith muốn tái sử dụng máy thống kê được phát minh vào năm 1890

Khoảng cách này được sử dụng vô cùng rộng rãi, đến mức nó có ảnh hưởng rất lớn đến các thiết bị đầu cuối, ví dụ VT52 (DEC). Phần lớn chúng đều được thiết kế để hiển thị với kích thước 80x24 (24 dòng, mỗi dòng 80 ký tự). Đến tận bây giờ, những ứng dụng mô phỏng terminal bật lên vẫn có kích thước mặc định là 80x24. Và tất nhiên, nó ảnh hưởng đến cả phong cách viết mã của chúng ta

Vấn đề là, tại sao công nghệ đang phát triển từng ngày, từng giờ mà một quy ước có lịch sử gần một thế kỷ vẫn được áp dụng. Thật khó có câu trả lời cho câu hỏi này. Tuy nhiên, theo tôi, lý do mà các thành viên lập trình vẫn tuân theo quy tắc này có liên quan đến tâm sinh lý của con người

Nếu dòng quá ngắn, chúng ta sẽ phải xuống dòng rất nhiều. Điều đó khiến chúng ta khó theo dõi mã hơn do nội dung bị ngắt quãng liên tục
Nếu dòng quá dài, việc của chúng ta phải nhìn chúng khá cổ. Hơn nữa, dòng dài có thể khiến chúng ta nhầm lẫn giữa các dòng với nhau. Tất nhiên, công việc này có thể tránh bằng cách tăng khoảng cách giữa các dòng, nhưng không phải trình chỉnh sửa nào cũng được.

Và mỗi dòng được khuyến mãi phải có từ 40-90 ký tự. (Tham khảo Markus Itkonen. Kiểu chữ và khả năng đọc. ) Và trung bình là 65 ký tự có vẻ là giá trị tốt nhất. Ngoài mã ra còn phải có thụt lề, căn chỉnh, giá trị này cần tăng lên một chút. Có lẽ vì lý do này, mà độ dài 80 vẫn được duy trì từ thời các bậc tiền bối của chúng ta đến tận bây giờ

Một số quy ước khác về độ dài dòng

132 ký tự một dòng là một định dạng cũng có hệ thống truyền tải khá lâu. Có thể nó bắt nguồn từ VT100 (DEC) có chế độ màn hình 132 ký tự và có liên quan đến máy in kim với 132 cột. 132 cũng có vẻ là giới hạn trên độ dài của mỗi dòng trong ngôn ngữ Fortran. Trên thực tế, đây cũng là độ dài lớn nhất được chấp nhận sử dụng trong cộng đồng lập trình viên. Mặc dù có một số chỗ vẫn có người viết những dòng dài hơn, ví dụ như

120 ký tự một dòng nhiều khi không được chấp nhận, cũng như 100 ký tự một dòng tùy chọn theo yêu cầu của đội. Lý do lựa chọn những giá trị này một phần cũng là do họ mặc khải

72 ký tự một dòng là giá trị thường được đề xuất với các nội dung dài như sách, báo. Ngoài ra, PEP 8 cũng đề nghị. Hơn nữa, 72 cũng là default line map của ngôn ngữ Fortran

thụt đầu dòng. tab so với. không gian

Tôi đã làm việc với nhiều ngôn ngữ, và tất cả đều được hướng dẫn kiểu viết mã là sử dụng toàn bộ dấu cách để thụt lề mã của mình. Tuy nhiên, xin mời tôi quay lại vấn đề giải quyết mà người ta khuyến nghị nên sử dụng tab, ví dụ như kiểu mã hóa Wordpress hay kiểu mã hóa nhân Linux. Do đó tại sao người dùng lại bảo vệ tab, người khác bảo đảm không gian. Use tab, or space, cái nào tốt hơn cái nào?

Bây giờ tôi biết rằng, thực ra cả thế giới vẫn còn tranh cãi nhau về việc này, dùng tab hay dấu cách. Cái nào tốt hơn cái nào. Ai cũng có những lý thuyết riêng của mình, cổ vũ việc dùng tab (or space) và chê bai những người đối lập. Một số lý do chính về việc sử dụng tab hoặc không gian có thể nói ngắn gọn lại như sau

At sao sử dụng tab

Đây là ký tự đúng nghĩa dùng để thụt lề. Một ký tự tab có nghĩa là thụt lề 1 mức, trong khi dấu cách có nhiều nghĩa khác nhau
Nó cho phép các thành viên lập trình với các tùy chọn khác nhau có thể thay đổi để thụt vào để nhìn khác nhau
Không thể thiếu tab ký tự thụt lề, nên bạn không phải lo vấn đề thụt lề khi sao chép, thụt lề bị xáo trộn do nguồn sử dụng 3 dấu cách, bạn sử dụng 4 dấu cách
Thụt lề bằng ký tự tab cho kích thước tệp nhỏ hơn
Việc di chuyển con trỏ qua các ký tự tab nhanh hơn
Nó là cách duy nhất để căn thẳng các cột nếu sử dụng phông chữ theo tỷ lệ

In sao sử dụng không gian

Bảo đảm việc hiển thị hệ thống tốt nhất giữa tất cả các thiết bị, trình chỉnh sửa với các thiết bị khác nhau. Dấu cách luôn có độ rộng là 1 cột
Tác giả viết mã có thể hoàn toàn làm chủ việc hiển thị thụt lề
Tab là ký tự không được hiển thị, nó thường được nhìn thấy giống như nhiều dấu cách liên tục

Gần đây mới có thêm một phương pháp thụt lề và căn chỉnh mới, đó là Tabstop đàn hồi. Tuy nhiên, có vẻ như nó vẫn chưa được các thành viên lập trình đón nhận, nên trong bài viết này, chúng ta tạm thời chưa đề cập đến nó

Phần tiếp theo sau đây, tôi sẽ trình bày những vấn đề cụ thể hơn, về việc sử dụng tab và không gian, và tất nhiên, cả những hạn chế của chúng

Khi nào thì việc sử dụng tab trở thành vấn đề?

Việc sử dụng tab để thụt lề, về cơ bản là không có vấn đề gì. Tuy nhiên, nó chỉ trở thành một vấn đề nếu yêu cầu chúng ta phải biết trước tab độ rộng. Có nghĩa là, mã có thể trông rất khác nếu độ rộng của tab thay đổi, thì khi đó, việc sử dụng tab mới là một vấn đề. Tất cả mọi trường hợp khác nhau, sử dụng tab hay không gian đều không có vấn đề gì cả

Sau đây, chúng ta sẽ tìm hiểu các trường hợp khác nhau về việc sử dụng tab và khoảng trắng trong định dạng mã

Trình chỉnh sửa xử lý thụt lề như thế nào

Tab và căn chỉnh

Thực hiện mở rộng tab (khoảng cách giữa các điểm dừng tab) và mở rộng độ lệch thụt lề (số ký tự mà dòng đó nhận vào) có thể có các giá trị khác nhau. Tuy nhiên, ở đây chúng ta chưa nhắc đến trường hợp phức tạp như vậy. Trong ví dụ sau, chúng tôi đánh giá trường hợp cả hai giá trị trên đều bằng nhau và bằng

int f(int x,
      int y) {
    return g(x,
             y);
}

7. Và chúng ta ký hiệu

int f(int x,
      int y) {
    return g(x,
             y);
}

8 tương ứng với 1 tab cho 1 mức thụt lề

int foo(char bar[]) {
--->int i = 0;
--->while(bar[i] != '\0')
--->--->i++;
--->return i;
}

Việc thụt lề như trên, bằng tab, hoạt động rất tốt với đoạn mã C ở trên. Kể cả khi chúng ta thay đổi độ rộng tab tùy theo sở thích của cá nhân, mọi thứ vẫn hoạt động bình thường, mã vẫn được định dạng rất đẹp

Vấn đề chỉ xảy ra với việc ngắt dòng. Khi một biểu thức bị ngắt ra thành nhiều dòng, chúng ta thường căn chỉnh chúng để dễ nhìn hơn

int f(int x,
      int y) {
    return g(x,
             y);
}

Chúng ta sẽ gọi khoảng trắng của dòng thứ 2 và dòng thứ 4 là dùng để “căn chỉnh”. Thật không may, rất nhiều biên tập viên sử dụng tab cho việc điều chỉnh cơ bản này, và chỉ thêm dấu cách (dưới đây sẽ ký hiệu là

int f(int x,
      int y) {
    return g(x,
             y);
}

9) với phần trống còn lại không đủ độ rộng của 1 tab. Lệnh này sẽ khiến các dòng bị ngắt phụ thuộc hoàn toàn vào tab độ rộng. Như ví dụ dưới đây, nếu chúng thay đổi tab từ

int f(int x,
      int y) {
    return g(x,
             y);
}

7 thành

int f(int x,
--->..int y) {
--->return g(x,
--->--->--->.y);
}

1, mọi thứ sẽ trở nên lộn xộn

int f(int x,
--->..int y) {
--->return g(x,
--->--->--->.y);
}

________số 8_______

Tuy nhiên, bạn có thể thấy rằng, dòng thứ 3 (_______6_______2), đây là dòng mà chúng ta chỉ thụt lề mà không căn cứ điều chỉnh gì. Nó không hề bị lệch lạc gì cả. Đó chính là một số ý tưởng để giải quyết vấn đề này. bỏ toàn bộ công việc chỉnh sửa

Tabs and not edit

Đây là phương án mà Visual Studio lựa chọn. Khi một biểu thức bị ngắt ra dòng mới, dòng đó chỉ đơn giản là được thụt lề thêm một hoặc hai mức nữa

int f(int x,
--->int y) {
--->return g(x,
--->--->y);
}

Nói một cách khác, số lượng khoảng trống đầu dòng luôn là bội số của phần bù thụt lề. Do đó, tab free is width và indent offset có giá trị bằng nhau, mã của chúng ta sẽ luôn được hiển thị một cách chính xác

Use way and not correct

Một phương án khác, khi bỏ việc chỉnh sửa căn bản, chúng ta có thể chuyển đổi toàn bộ dấu tab thành dấu cách mà mã không bị ảnh hưởng gì

int f(int x,
....int y) {
....return g(x,
........y);
}

Tuy nhiên, code này chưa được đẹp lắm. Và những người cổ đại vũ công sử dụng dấu cách thường sử dụng phương án sau đây

Use way and căn chỉnh

Việc không điều chỉnh làm cho mã trông không đẹp và được cho là khó đọc. Và lý do tại sao những người dùng lại cho rằng không nên sử dụng tab, đó là tab không thể đảm bảo công việc căn cứ điều chỉnh luôn luôn đúng, trong khi có thể làm được công việc này

Nếu chúng ta chỉ sử dụng dấu cách cho cả thụt lề và căn chỉnh, như ví dụ dưới đây

int f(int x,
......int y) {
....return g(x,
.............y);
}

Kết quả là, mã của chúng ta sẽ luôn được hiển thị chính xác với mọi hệ thống và trình soạn thảo. Bởi vì dấu cách là như nhau ở mọi nơi

Tuy nhiên, công việc này cũng có những vấn đề của riêng nó. Việc sử dụng dấu cách sẽ cố định indent offset. Và khi làm việc với những tập tin này, chúng ta sẽ phải thiết lập lại trình soạn thảo cho phù hợp. Đây sẽ là một nỗi kinh hoàng lớn nếu một người làm việc với nhiều dự án có kiểu thụt lề khác nhau. Nếu bạn muốn indent offset tăng hoặc giảm, bạn phải sửa lại toàn bộ tập tin. Sử dụng tab có thể giải quyết vấn đề này, tuy nhiên, lại gặp vấn đề cơ bản và chúng ta có thể giải quyết vấn đề bằng phương pháp sau đây

Use smart tabs

Có một cách để chúng ta có thể sử dụng tab và vẫn đảm bảo việc căn chỉnh hoạt động đúng, đó là sử dụng tab để thụt lề và cách để căn chỉnh (còn có tên gọi khác là tab thông minh – tab thông minh). Ví dụ, chúng ta có thể sử dụng các tab thông minh như ví dụ dưới đây

int f(int x,
......int y) {
--->return g(x,
--->.........y);
}

Việc sử dụng tab chỉ thực hiện sự cố có vấn đề nếu chúng ta sử dụng lộn xộn cả tab và khoảng trắng. Cách giải quyết là, sử dụng khoảng trắng để căn chỉnh các ký tự và sử dụng tab để thụt lề. Như ví dụ trên, khi chúng tôi điều chỉnh độ rộng của tab về

int f(int x,
--->..int y) {
--->return g(x,
--->--->--->.y);
}

1, mã sẽ trông giống như dưới đây

int f(int x,
......int y) {
->return g(x,
->.........y);
}

Nó hoàn toàn bình thường, vẫn được thụt vào và căn chỉnh tốt. Đó là bởi vì, các dòng bị ngắt được bắt đầu bằng cách thụt lề ngang với dòng trước đó, sau đó sử dụng dấu cách để căn chỉnh. Nói một cách khác, việc sử dụng các tab thông minh để tạo tệp có thể có phần bù thụt lề là bất kỳ giá trị nào

Huỷ bỏ chế độ sử dụng tab

Đương nhiên, kể cả khi sử dụng tab thông minh, chúng ta vẫn có thể gặp phải những vấn đề nhất định. Đó là khi chúng ta muốn căn chỉnh comment cho các dòng với indent other nhau

int foo(char bar[]) {     // Indent level 0
--->int i = 0;            // Indent level 1
--->while(bar[i] != '\0') // Indent level 1
--->--->i++;              // Indent level 2
--->return i;             // Indent level 1
}                         // Indent level 0

int f(int x,
      int y) {
    return g(x,
             y);
}

0

Trong ví dụ trên, chỉ những nhận xét cho mức độ thụt lề mới được căn cứ khi chúng ta thay đổi độ rộng tab từ

int f(int x,
      int y) {
    return g(x,
             y);
}

7 thành

int f(int x,
--->..int y) {
--->return g(x,
--->--->--->.y);
}

5

Với những trình soạn thảo hiển thị tab dấu là “một số lượng

int f(int x,
--->..int y) {
--->return g(x,
--->--->--->.y);
}

6 cột” thì chúng ta có thể thêm tab dấu vào trước nhận xét để căn chỉnh như ví dụ sau đây. Tuy nhiên, phần lớn các trình soạn thảo mà tôi sử dụng, cả Emacs hay Vim, để hiểu dấu tab là “chuyển đến cột tiếp theo là tổng hợp của

int f(int x,
--->..int y) {
--->return g(x,
--->--->--->.y);
}

6”, nên phương án này không khả thi

int f(int x,
      int y) {
    return g(x,
             y);
}

1

int f(int x,
      int y) {
    return g(x,
             y);
}

2

Tuy nhiên, trong trường hợp này, việc bình luận nội tuyến không thể là ý tưởng tốt. Việc comment như dưới đây dễ dàng hơn nhiều cho cả người viết và người đọc code

int f(int x,
      int y) {
    return g(x,
             y);
}

3

Do that end. tab hay không gian?

Việc sử dụng tab hay không gian đều có những ưu điểm và nhược điểm riêng. Việc sử dụng các ký tự nào cũng không phải là vấn đề. Điều quan trọng nhất là sự quán nhất. Chọn một kiểu thụt lề và căn chỉnh cho cả dự án và tất cả mọi người đều hành theo. Sự thật hệ thống đó sẽ đảm bảo được mã của bạn sẽ dễ dàng duy trì hơn sau này. Unknown is it used tab or space

thụt đầu dòng. 2 so với. 4 so với. số 8

Lại thêm một vấn đề nữa với thụt lề. Thế mới biết, riêng việc thụt thôi mà cũng nhiều lắm khê. Và cũng vì thế mà chúng ta biết được, việc indent code quan trọng thế nào

Tạm dừng tab vấn đề hoặc không gian sang một bên. Cho phép bạn sử dụng tab, hay không gian, bạn cũng sẽ gặp phải một vấn đề khác. That is indent offset bao nhiêu là vừa. Vấn đề này có thể ít gặp hơn với người sử dụng tab, bởi vì nếu họ thích có thể dễ dàng thay đổi giá trị của sự bù đắp. Những người sử dụng không gian chắc chắn hơn. Họ có phải sửa giá trị phần cứng này ngay từ đầu không

Tuy nhiên, ở phần này, chúng ta không nói đến những vấn đề đó, mà chỉ tập trung vào indent offset mà thôi. Indent offset cũng được đề cập rất khác nhau giữa các ngôn ngữ và các tổ chức

Thụt lề 2

Thụt lề 4

Thụt lề 8

Theo một số nghiên cứu, mà tôi không nhớ đã đọc ở đâu, indent offset là 6 sẽ khiến code nhìn xấu và rất khó đọc. Các giá trị khác nhau chắc chắn tương tự. Có thể vì thế mà tôi chưa thấy ai đặt bù đắp bằng các giá trị như 3 hay 5. Ngoài ra, các thành viên lập trình thường được hưởng lợi từ sự tích lũy của hai, nên các giá trị trên thường được sử dụng

Có một lợi ích của công việc indent offset lớn, đó là nó sẽ dễ dàng nhận ra các khối lệnh con của một lệnh điều khiển nào đó (chẳng hạn như

int f(int x,
--->..int y) {
--->return g(x,
--->--->--->.y);
}

8 chẳng hạn). Ví dụ, bạn có thể nhìn vào 3 ví dụ dưới đây với 3 khoảng cách thụt lề khác nhau

int f(int x,
      int y) {
    return g(x,
             y);
}

4

int f(int x,
      int y) {
    return g(x,
             y);
}

5

int f(int x,
      int y) {
    return g(x,
             y);
}

6

Rõ ràng là việc thụt lề lớn hơn, khiến chúng ta dễ dàng nhận ra các khối lệnh bên trong

int f(int x,
--->..int y) {
--->return g(x,
--->--->--->.y);
}

8 và

int f(int x,
->..int y) {
->return g(x,
->->->.y);
}

0 hơn là offset nhỏ. Tuy nhiên, một điều kiện hạn chế của việc đặt offset lớn, đó là phần còn lại của dòng sẽ nhỏ đi, có nghĩa là số ký tự bạn có thể viết trên dòng đó sẽ ít đi

Do đó must set offset is bao nhiêu cho vừa, để cân bằng giữa việc dễ đọc và việc phải ngắt dòng. This thing may be phụ thuộc vào ngôn ngữ và từng dự án cụ thể. Ví dụ ngôn ngữ Ruby, hầu như tất cả mọi người đều sử dụng indent offset là 2. Có thể một phần lý do là mã của ngôn ngữ này thường khá dài, nếu đặt offset có thể tạo ra một dòng bị ngắt nhiều hơn

Những ngôn ngữ ít bị ngắt dòng hơn nên sử dụng indent offset 4. Riêng offset 8 tôi mới thấy vài ví dụ về công việc code ngôn ngữ C, mà chưa thấy chỗ nào khác đề nghị công việc này. Một số nơi đề nghị sử dụng tab để thụt lề cũng không nói cần bù đắp là bao nhiêu cho vừa. Họ để chọn thành viên tự quyết định thiết lập. Lý do, theo tôi, đó là các lý do trong những phần mềm này rất phức tạp, và việc cần hiểu các khối lệnh là yêu cầu quan trọng nhất, nên việc thụt lề lớn để dễ nhìn cũng dễ hiểu.

Do đó, 2, 4 hay 8, indent offset bao nhiêu là vừa. Tất nhiên là phải tùy chọn vào biểu tượng của ngôn ngữ và của dự án nữa. Nhưng nếu cần phải lựa chọn giữa các giá trị này, thì có vẻ như 4 là một lựa chọn an toàn

giai đoạn kết thúc câu. 1 không gian vs. 2 dấu cách

Vào thời điểm này, giữa thập kỷ thứ hai của thế kỷ 21, điều này nghe có vẻ ngu ngốc. Có bao giờ bạn nghe ai đó bảo, nên thêm hai dấu cách vào sau dấu chấm chưa? . Lúc mới nghe, điều đó thật dị thường. Nhưng sau khi tìm hiểu, thì tôi mới biết rằng, điều đó được coi như từng được coi là bình thường, rất lâu trước đây

Máy đánh chữ xuất hiện cuối thế kỷ 19. Cơ chế hoạt động của nó dựa trên chuyển động của các bánh răng. Chính vì thế mà nó nảy sinh một vấn đề. Chữ cái

int f(int x,
->..int y) {
->return g(x,
->->->.y);
}

1 và chữ cái

int f(int x,
->..int y) {
->return g(x,
->->->.y);
}

2 luôn chiếm phần không gian trên trang giấy như nhau. Vì vậy, các phông chữ đơn cách nhau (hay còn gọi là chiều rộng cố định) được thiết kế để giảm khoảng trống của các chữ cái hơn, vì vậy với việc sử dụng các phông chữ truyền thống theo tỷ lệ. Tuy nhiên, với phông chữ này, các chữ cái không thể lồng vào nhau được

Nhiều người thường cho rằng, việc sử dụng hai dấu cách sau dấu chấm bắt nguồn từ việc sử dụng phông chữ đơn cách của máy đánh chữ. Bởi các ký tự đơn cách đã có sẵn khoảng cách nên cần có khoảng cách lớn hơn giữa các câu để phân biệt. Tuy nhiên, thực tế, việc sử dụng dấu cách dài đã có hệ thống truyền trước đó hàng trăm năm. Và những người đánh máy sử dụng hai dấu hiệu để phù hợp với truyền thống mà thôi

Một số lưu ý về thuật ngữ, “dấu cách kép” (không có gạch nối) yêu cầu hai dấu cách liên tiếp được nhập, “dấu cách kép” (có gạch nối), hoặc “dấu cách rộng” là một ký tự, chỉ

Những ví dụ sau đây cho thấy công việc trong ấn truyền thống (thời chưa có máy đánh chữ) sử dụng dấu cách kép – cũng là emspace – sau dấu chấm như một quy ước. Rõ ràng, một số lượng lớn các quy ước cũ trong ngành chế độ đã thay đổi theo tháng

Hình ảnh dưới đây là tài liệu vào năm 1787, emspace được sử dụng thường xuyên (phần khoanh đỏ). Lưu ý thêm rằng, vào thời điểm này, người ta vẫn sử dụng dấu cách trước dấu hai chấm (phần màu xanh), và đặc biệt là dấu rất lạ. dấu cách – hai chấm – emdash (phần màu xanh góc trên bên phải). Ngày nay, những kiểu trình bày văn bản như vậy đã không còn tồn tại nữa

Hình ảnh dưới đây là tài liệu được lấy vào những năm 1840. Dấu emspace (khoanh đỏ) và dấu cách trước chấm com (khoanh xanh) vẫn tiếp tục được sử dụng

Năm 1855, mọi thứ vẫn chưa thay đổi gì

Năm 1876, mọi thứ vẫn tiếp diễn. Dấu emspace after dấu chấm vẫn còn nguyên

Năm 1892, dấu emspace vẫn rất được tin dùng. Chú ý dấu gạch nối (khoanh xanh) giữa các từ mà ngày nay chúng được viết liền. Đến tận năm 1909, từ “hôm nay” mà chúng ta dùng ngày nay vẫn được viết là “to-day”

Năm 1928, một khoảng thời gian rất dài, mọi chuyện chưa có gì mới

Một cuối sách tiếng Tây Ban Nha năm 1959 vẫn sử dụng emspace, và cả hai dấu phẩy sau emdash. Không biết đây là lỗi đánh máy hay thời đó, người ta viết như vậy

Một cuốn sách năm 1960 của nhà thơ E. E. Cummings. There are as emspace is used

Vào năm 1961, mọi chuyện bắt đầu thay đổi

Vào những năm sau đó, 1963 và 1964, việc sử dụng một dấu cách sau dấu chấm đã trở thành tiêu chuẩn

Có thể chấp nhận dấu cách đơn trong ngành in ấn là một biện pháp tiết kiệm giấy tiết kiệm?. ?. Mặc dù xuất hiện từ thế kỷ 19, nhưng cuốn sách về cổng mềm mới phổ biến trên thị trường từ những năm 1930. Các nhà xuất bản phân phối các cuốn sách nhiều tới mức định lượng, họ phải ở hàng ngàn cuốn sách

Và để tiết kiệm điện, các biện pháp thu nhỏ lề, giảm khoảng cách các dòng, v. v đã được áp dụng. Có thể việc sử dụng một dấu cách cũng bắt đầu từ đây. Sự phát triển nhanh chóng của ngành công nghiệp xuất bản có thể là lý do để đánh dấu cách đơn vị được chấp nhận nhanh chóng như vậy, mặc dù nó ngược lại với hàng thế kỷ truyền thống

programming python

Python thụt lề tab

chiều dài dòng. tại sao luôn là 80?

Ngược dòng lịch sử

Một số quy ước khác về độ dài dòng

thụt đầu dòng. tab so với. không gian

Khi nào thì việc sử dụng tab trở thành vấn đề?

Trình chỉnh sửa xử lý thụt lề như thế nào

Tab và căn chỉnh

Tabs and not edit

Use way and not correct

Use way and căn chỉnh

Use smart tabs

Huỷ bỏ chế độ sử dụng tab

Do that end. tab hay không gian?

thụt đầu dòng. 2 so với. 4 so với. số 8

giai đoạn kết thúc câu. 1 không gian vs. 2 dấu cách

Bài Viết Liên Quan

Quảng Cáo

Có thể bạn quan tâm

Toplist được quan tâm

Quảng cáo

Xem Nhiều

Quảng cáo

Chúng tôi

Điều khoản

Trợ giúp

Mạng xã hội