Bir dilde duyarsız anahtar kelimeleri vaka [kapalı]

Özel bir betik dili yazmaya çalışıyoruz. Büyük / küçük harfe duyarsız anahtar kelimeler sunarak dili bağışlama konusunda bir öneride bulunuldu .

Şahsen bu fikri sevmiyorum, ama ekibimde son kullanıcı mutlu edeceğini söyleyen birkaç kişi var. FORTRAN, BASIC, SQL gibi dillerin örnekleri, bunların büyük / küçük harf duyarlı olmadığını söyleyerek verilmektedir.

Bu iyi bir fikir mi?

Kendinize son kullanıcının kim olduğunu sorun. C veya Javscript'te programlama tecrübesi olan veya Unix'te BT tecrübesi olan biri tarafından yazılmak isteniyorsa, büyük / küçük harf duyarlılığı muhtemelen yapılacak en doğru şeydir, çünkü kullanıcının beklediği şey budur. Ancak çoğu son kullanıcı ve hatta güç kullanıcıları için bu kafa karıştırıcı olacaktır.

VB / VBA / VBScript büyük / küçük harfe duyarsızdır ve bu, programcı olmayanların dilin kolayca anlaşılmasını sağlamak için verilen bir karardı. Excel formülleri, tam olarak komut dosyaları değil, birçok kullanıcı eline ulaştığında, büyük / küçük harf duyarlı değildir. Çoğu yazılarda durum seçimi metnin az çok profesyonel ve cilalı görünmesine neden olabilir, ancak durum kendini kelimelerin anlamsal anlamını değiştirmez . Bu yüzden geliştiricilerin büyük küçük harf duyarlı bir komut dosyası dili ile karıştırılmayacağına inanıyorum.

Yine, bu teknik bir seçim değil. Hedef kitleyi iyi bilen insanlar tarafından yapılması gereken bir ürün yönetimi seçeneğidir.

Sunmak istediğiniz kullanıcı deneyimine dayanarak karar vermelisiniz, ne kadar kolay ya da zor değil.

Kullanıcılarınızın büyük / küçük harf duyarlılığına sahip olmamasını kolaylaştıracaksa, uygulamanız gereken budur.

Bir noktada SQL, büyük / küçük harf duyarlı değildir. Bu etkileşimli bir ortamda kullanımı çok kolaylaştırır.

Bu bakmak için başka bir yol yoktur hiç arasında bir fark olacaktır keywordve Keywordkendi dilinizde ve bu fark kullanıcıya anlamlı olacak? Bir betik dili için cevabın "hayır" olduğunu söyleyebilirim.

Programlama dilleri büyük / küçük harfe duyarlı olmalıdır. İnsanlar bunu çok kolay bir şekilde ayarlayabilirler: basitçe çoğunlukla küçük harflerle çalıştıklarını ve mevcut API'lerde karma durumdaki veya tümü büyük harf tanımlayıcılarına dikkat etmeleri gerektiğini hatırlatmaları gerekir.

Bir zamanlar dilleri büyük-küçük harf duyarlı hale getirmek açıktı. Bunun nedeni, küçük harflerin tüm bilgisayar sistemlerinde ve bunların G / Ç aygıtlarında (klavyeler, yazıcılar ve ekran aygıtları) bulunmamasıdır. Programlama dili uygulamaları, yalnızca gösterilebilecek veya yazdırılabildiğinden büyük harfle yazılmış programları kabul etmek zorunda kaldı. Ve bunun için büyük / küçük harf duyarsız olmaları gerekiyordu, çünkü büyük harfleri kabul etmek ve aynı zamanda büyük / küçük harf duyarlı olmak, küçük harfleri reddetmek anlamına geliyor. Küçük harf, programcıların istediği bir şeydi ancak her zaman olamazdı. Hiç kimse gerçekten büyük harfle bağıran programlarla çalışmak istemedi; sadece bir donanım sınırlamasıydı.

Bir süre, terminallerde kılıf katlama yapılması bile yaygındı. Bir terminal yalnızca büyük harf gösterebilirse, ancak büyük ve küçük harfleri destekleyen bir hesaplama sistemine giriş yapmanız gerekiyorsa, terminal küçük harfleri büyük harfe katlar. Sence bu çok mu uzun zaman önceydi? "Apple II'de olduğu gibi, Apple II Plus'da da küçük harf işlevi yoktur." (http://en.wikipedia.org/wiki/Apple_II_Plus) İlk Apple bilgisayarlarının kullanıcıları karışık içerikli bir BBS'ye çevrildiğinde, terminal emülatörü (veya ana bilgisayar) hepsini büyük harfe katlamak zorunda kaldı. Tüm büyük harflerle yazılmış mesajlar o günlerde ilan panolarında yaygındı. Bu işlevsellik hala Linux çekirdeği gibi Unix benzeri işletim sistemlerinde bulunur. Örneğin,stty olcuc kabuk isteminize şunu yazın.Unix tty çizgi disiplini, küçük harfleri çıkışta üste doğru ve büyük harfleri girişe kadar düşürebilir. Bu, küçük harf programlama dilinde, küçük harf olmayan bir terminal üzerinde çalışmanıza izin verir.

Büyük / küçük harfe duyarsızlık, modernize edilmiş bilgisayarların modern dünyasında çok iyi çalışmayan eski bir bilgisayar çağından kalma modası geçmiş bir kavramdır. Bunu diğer dillere mi genişletiyorsun? Peki ya Fransızca: È ve è'nin eşdeğer olduğunu düşünüyor musunuz? Veya Japonca? Hiragana ve katakana'nın sadece vakalar olduğunu düşünüyor musunuz, böylece フ ァ イ ル ve ふ ぁ い る aynı tanımlayıcılar mı? Bu tür bir aptallık desteği, tüm Unicode alanı için büyük / küçük harf eşdeğer haritalarına sahip olacak olan sözcük çözümleyicinizi büyük ölçüde karmaşıklaştıracak.

Matematiğin büyük / küçük harfe duyarlı olduğunu unutmayın. Örneğin, büyük harf sigması toplamı, küçük harf sigması ise standart sapma gibi başka bir şeyi belirtir. Bu, aynı formülde herhangi bir zorluk yaratmadan meydana gelebilir. (Programlama dili Σ ve σ'ye eşdeğer mi olur?)

İngilizce yazım duyarlıdır. Örneğin, birçok uygun isim, sıradan isimlere ve hatta konuşmanın diğer kısımlarına karşılık gelir. "may" bir fiildir, ancak "May" bir ay veya bir kadının adıdır. Ayrıca, bir kısaltma veya kısaltma küçük harfle yazılmışsa, kafa karıştırıcı olabilir. SAT, skolastik yetenek testi anlamına gelirken, "oturmak", "oturmak" için geçmiş zaman katılımcısıdır. Akıllı insanlar, ayrıntıya dikkat etmeye ve düzgün şekilde büyük harf kullanmaya özen gösterir.

Temel olarak, 1985'ten beri oluşturulan ve büyük / küçük harfe duyarlı olmayan herhangi bir yeni programlama dili, E-POSTALARDA VE İKİNCİ BİR DÜŞÜNCÜ OLMADAN POSTA'DA NEREYE GİDİLECEĞİNDİR?

Diliniz kodu başka bir dile çevirmek için bir kod oluşturma hedefi olarak kullanılmışsa ve diğer dilin büyük / küçük harf duyarlı olması durumunda ne olur? Ayrımı yakalamak için bir şekilde tüm isimleri dönüştürmeniz gerekecek. (Yani bunun teknik bir karar olmadığını ve hedef kitlenin sadece duygusal tercihlerinin meselesi olduğunu iddia etmek saçma).

Dosyalar başka bir işletim sisteminden alındığında, Windows'ta durum ele almanın neden olduğu rahatsız edici sorunlara bakın. Bu teknik bir mesele. Büyük küçük harf duyarlı dosya sistemleri, büyük küçük harf duyarlı olmayanların sahip olmadığı yabancı verilerle ilgili bir sorun yaşamaktadır.

Common Lisp ideal yaklaşıma değindi: sembol adları büyük / küçük harf duyarlıdır ancak belirteçler okunduğunda büyük harfe katlanırlar. Bu araçlar bu belirteçleri foo, fOO, FOOve Footüm göstermektedirler aynı sembol: adı karakter dizesi olarak depolanır sembolü "FOO". Ayrıca, bu davranış yalnızca varsayılan okuma tablosu yapılandırmasıdır. Okuyucu harfleri büyük harfe, küçük harfe, büyük harfe çevirebilir veya koruyabilir. Son iki seçenek büyük / küçük harf duyarlı bir lehçeye yol açar. Bu sayede kullanıcılar maksimum esnekliğe sahiptir.

Asıl belirleyici faktör, ne kadar sıklıkla aynı ada sahip birden fazla şeye sahip olmak isteyeceksinizdir. Büyük / küçük harf duyarsızlığı SQL'de çalışır, çünkü genellikle bir sütun istemezsiniz SELECT. Java'da can sıkıcı olurdu, çünkü diğer tüm satırlar Object object = new Object()aynı adın bir sınıfa, bir örneğe ve bir yapıcıya başvurmasını istediğiniz yere benziyor .

Başka bir deyişle, büyük / küçük harf duyarlılığı, bir adı aşırı yüklemek için çoğunlukla yararlıdır ve aşırı yükleme, büyük, karmaşık projelerde çoğunlukla yararlıdır. Bir kodlama dili gibi daha seyrek kullanım için, büyük / küçük harf duyarlılığı programlamayı çok daha basit hale getirebilir.

Bir keresinde, tanımlayıcıların sadece büyük / küçük harfe duyarsız olmadığı, beyaz boşluktan duyarsız olduğu bir kural dili yapmıştım. Ayrıca, aynı tanımlayıcıya atıfta bulunan diğer adların oluşturulmasına izin verdim. Örneğin, ProgrammersStackExchange, programcı yığını değişimi ve PSE'nin hepsi aynı sembole çözümlendi ve birbirlerinin yerine kullanılabilir.

Etki alanım için çok iyi çalıştı, çünkü etki alanı aynı şeyi ifade etmek için çok iyi bilinen bir yol kullanıyordu ve isimlendirme çatışmaları nadirdi. Hiç kimse bir isim kullanarak bir sorgu yazarak ve sonucun bir başkasını kullanmasıyla şaşırmaz. Dil desteğinin sağlanması, etki alanı ile programlama dili arasında çeviri yapmayı çok kolaylaştırdı. Bununla birlikte, bir değişkene yapılan tüm referansları bulmak gibi bazı işleri daha da zorlaştırdı. Neyse ki, benim durumumda bu tür durumlar nadiren ortaya çıkıyor ya da yardımcı olacak araç desteği oluşturmak için oldukça kolaydı, ancak kendi durumunuzu hesaba katmanız gerekiyor.

Komut dilinizin büyük / küçük harfe duyarlı olacağı varsayılmıştır - değişken adını veya anahtar kelimesini yanlış durumda kullanarak yazım hatası yapıp kullanmadığını söyleyen bir derleyici veya sözdizimi denetleyicisi mi oluşturacaksınız? Olmazsa, bu dil olayını duyarsız hale getirmek için çok güçlü bir argüman olacaktır.

Değişkenleri anında bildirir misiniz? Öyleyse, büyük / küçük harfe duyarlı olmama karşı savunuculuğa neden olurdum.

ATypo = 42; 

aksine

Atypo = 42; 

Gereksiz yere hata ayıklama süresi istiyor, iki ifadenin eşdeğeri olması hayatı kolaylaştırıyor.

FORTRAN, BASIC, SQL gibi dillerin örnekleri, bunların büyük / küçük harf duyarlı olmadığını söyleyerek verilmektedir.

FORTRAN ve SQL (ve COBOL) 'un küçük harf duyarsız olmasının nedeni, normal karakter kümelerinin yalnızca büyük harflere sahip olduğu makinelerde kullanılmak üzere tasarlandıklarıdır. Bu dillerdeki büyük küçük harf duyarlılığı (en azından), bir dil tasarım seçiminden çok daha eski bir eserdir.

Şimdi, daha fazla affedici olanın duyarsızlığının olduğunu iddia edebilirsin, ama bunun ters tarafı, vaka duyarlılığının, daha okunabilir bir kodla sonuçlanabileceğidir;

Büyük küçük harf duyarlılığı zararlı olarak kabul edildi.

Yaşam büyük / küçük harfe duyarlı değildir ve kullanıcılar veya programcılar da değildir.

Büyük / küçük harfe duyarlı diller, büyük / küçük harfe duyarlı olmayan karşılaştırmaları zorlaştıran kısıtlı sistemlerin tarihi bir kazasıdır. Bu handikap artık yok, bu yüzden bir daha büyük küçük harf duyarlı bilgisayar sistemi yapmak için hiçbir sebep yok.

Büyük küçük harf duyarlılığının kötü olduğunu söyleyecek kadar ileri giderdim , çünkü bilgisayarın rahatlığını kullanıcınınkinden daha önce gösteriyor.

(İlgili, birkaç yıl önce hatırladım, bazı dahi, kredi kartı faturasını ödemeyi reddetti, çünkü adı büyük harfliydi, ancak karışık dava yazdı. Ödeme için geçerli bir talep: Hakim, iddiaya hak ettiği gibi davrandı.

Kişisel deneyimime göre, büyük / küçük harfe duyarlı ve duyarsız diller arasında büyük bir fark görmüyorum.

Daha da önemlisi, bir programcının kodunda tutması gereken ve derleyici ya da çözümleyici olmayanlar tarafından kontrol edilmesi gereken adlandırma ve yapısal kurallardır. Bazı kurallara sadık kalırsanız, kolayca uygun bir isim bileceksiniz (değişken checkOut veya CheckOut değişkenini seçtiğinizi düşünmezsiniz) ve kodunuz büyük / küçük harf duyarlı ve okunması kolay olacaktır.

Kişi aynı şekilde CheckOut ve checkOut ve checkout ve cHeCkOuT ve CHECKOUT kullanmamalı. Okunabilirliğe zarar verecek ve bu tür kodların daha acı verici bir şekilde anlaşılmasını sağlayacaktır (ancak kodun okunabilirliğini yok etmek için yapılabilecek daha kötü bir şey vardır).

Bir tür kural kullanırsanız, örneğin göreceksiniz:

CheckOut.getInstance () - checkOut.calculate () adında bir sınıfın statik yöntemidir - değişken veya genel alanda _checkOut.calculate () adı verilen bir nesnenin yöntemidir - CHECKOUT adlı özel alanda tutulan bir nesnenin yöntemi - bu bir son statik veya sabit alan / değişken

diğer bazı dosyaları veya dosyanın parçalarını kontrol etmeden. Daha hızlı okuma kodu yapar.

Benzer kuralları kullanan pek çok geliştirici görüyorum - sıklıkla kullandığım dillerde: Java, PHP, Action Script, JavaScript, C ++.

Nadir bir durumda, büyük / küçük harf duyarsızlığı konusunda öfkeli olabilir - örneğin, bir sınıf adı için CheckOut kullanmak ve bir değişken için checkOut kullanmak istediğinizde ve birbiriyle çarpıştığı için olamaz. Ancak, hassasiyeti korumak ve onu adlandırma kurallarında kullanmak için kullanılan bir programcının sorunu. Birinin büyük / küçük harf duyarlı olmayan bir dilde standart önek veya sonek ile kuralları olabilir (VB'de programlamıyorum ancak birçok VB programlayıcısının bu tür adlandırma kurallarına sahip olduğunu biliyorum).

Birkaç kelimeyle: Büyük / küçük harf duyarlılığını daha iyi görüyorum (sadece nesne yönelimli diller için) çünkü geliştiricilerin çoğu büyük / küçük harf duyarlı dilleri kullanıyor ve çoğu büyük küçük harf duyarlılığına dayalı adlandırma kuralları kullanıyor, böylece büyük / küçük harf duyarlı olmak için daha iyi bir dil istiyorlar. Bir tür değişiklik yapmadan kendi kurallarına sadık kalabiliyorum. Ancak bu, oldukça dini bir argümandır - nesnel bir değil (gerçek dezavantajlara veya dava duyarlılığının iyi yanlarına dayanmaz) - çünkü iyi bir geliştiriciye gelince, bir bAd DeVeLoPeR söz konusu olduğunda, kabusun kodunu üretebilecek bir şey göremiyorum. Büyük küçük harf duyarlılığı olsa bile, bu büyük bir fark değil.

Programlama dilleri büyük / küçük harf duyarlı olmamalıdır.

Bu günlerde birçok dilin ana nedeni büyük / küçük harf duyarlıdır, basitçe kargo kültü dil tasarımıdır: "C böyle yaptı ve C inanılmaz derecede popüler, bu yüzden doğru olmalı." Ve diğer pek çok şeyde olduğu gibi, C de bunu belirgin bir şekilde yanlış yaptı.

Bu aslında C ve UNIX'in ardındaki itici felsefenin bir parçasıdır: Uygulanması kolay olan kötü bir çözüm ile uygulanması daha zor olan iyi bir çözüm arasında bir seçeneğiniz varsa, kötü çözümü seçin ve etrafınızdaki çalışma yükünü zorlayın Kullanıcı. Bu snark gibi gelebilir, ama kesinlikle doğru. "En kötüsü daha iyi ilke" olarak bilinir ve son birkaç on yılda milyarlarca dolarlık zarardan doğrudan sorumludur, çünkü C ve C ++, aksaklık ve güvensiz yazılım yazmayı çok kolay hale getirmiştir.

Bir dil vakasını duyarsız hale getirmek kesinlikle daha kolaydır; Herşeyin büyük / küçük harfe duyarsız bir şekilde eşleşmesini sağlamak için ek iş yapmak zorunda kalmadan, lexer, parser ve sembol tablolarına ihtiyacınız yoktur. Ancak iki nedenden ötürü de kötü bir fikir:

• Öncelikle, özellikle bir betik dili oluşturuyorsanız, bir yerde bir yerde "myObject" ve diğerinde "MyObject" olarak adlandırdığınız, açıkça aynı nesneye atıfta bulunduğunuz ancak büyük harfle biraz tutarsızlaştığınız basit bir yazım hatası , bir çalışma zamanı hatasına dönüşmez. (Bu Python gibi yanlış anlayan betik dillerinde büyük bir acı noktası olarak rezildir.)
• İkincisi, büyük / küçük harfe duyarlılığa sahip olmamak , büyük / küçük harf değiştirmek suretiyle büyük / küçük harf duyarlılığının , aynı kelimenin aynı kapsamdaki iki farklı şeyi ifade etmesiyle kötüye kullanılamadığı anlamına gelir . Eğer bir C ortamında Windows koduyla çalışmak zorundaysanız ve bunun gibi çirkin bildirimlere maruz kaldıysanız HWND hwnd;, tam olarak neden bahsettiğimi anlayacaksınız. Böyle yazması gerekenler dışarı atılıp vurulmalı ve dili büyük / küçük harfe duyarsız hale getirmek büyük / küçük harf duyarlılığı kötüye kullanımının kodunuza girmesini önler.

Öyleyse doğru yapmak için ekstra çaba gösterin. Sonuçta ortaya çıkan kod daha temiz, okunması kolay, daha az paramparça olacak ve kullanıcılarınızı daha üretken kılacak, ve bu herhangi bir programlama dilinin asıl amacı değil mi?

Birisinin "büyük küçük harf duyarlılığının kod okumayı kolaylaştırdığını" söylediğine inanamıyorum.

Kesinlikle hayır! Bir iş arkadaşının omzuna Şirket ve şirket (halka açık değişken Şirket, özel değişken şirket ile eşleşmiş şirket) adı verilen değişkenlere baktım ve yazı tipi ve renk seçimi, ikisi arasındaki farkı söylemeyi zorlaştırıyor - birbirlerinin yanındayken bile.

Doğru ifade, "karma harf, okuma kodunu kolaylaştırır" olmalıdır. Bu çok daha açık bir gerçektir - örneğin, şirket ismi yerine Şirket Adı ve Şirket Adresi olarak adlandırılan değişkenler. Ancak bildiğim hiçbir dil sizi yalnızca küçük harfli değişken isimleri kullanmaz.

Bildiğim en çılgınca kongre "büyük, küçük, özel". Sadece sorun istiyor!

Benim hatam benim "birşeyin sessizce başarısız olmaktan ziyade en kısa sürede başarısız olması ve başarılı görünmesi daha iyi" dır. Ve derleme zamanından daha erken olamaz.

Büyük harf kullanmak istediğinizde yanlışlıkla bir küçük harf değişkeni kullanırsanız , aynı sınıfa atıfta bulunuyorsanız , genellikle derlenir . Bu nedenle, hem derleme hem de çalışma zamanında başarılı olmuş gibi görünüyorsunuz, ama ustaca yanlış bir şey yapıyor olabilirsiniz ve belki de uzun süredir bulamıyorsunuzdur. Yanlış bir şey olduğunu tespit ettiğinde

Özel değişkenin sonekinin olduğu bir sözleşmeyi kullanmak çok daha iyi - örneğin, Şirket genel değişkeni, ŞirketP özel değişkeni. Hiç kimse yanlışlıkla ikisini karıştırmayacak ve birlikte istihbaratta ortaya çıkacaklar.

Bu, insanların önceden tanımlanmış bir özel değişken olan pCompany'in intellisesne'de iyi bir yerde görünmeyeceği Macar gösterisine itiraz etmesiyle karşı çıkan bir itiraz ile çelişmektedir.

Bu kongre, korkunç büyük / küçük harf konvansiyonunun tüm avantajlarına sahiptir ve sakıncaları yoktur.

İnsanların değişkenler arasında ayrım yapmak için büyük / küçük harf duyarlılığına itiraz etme ihtiyacı duymaları gerçeği, bence hem hayal gücü eksikliği hem de sağduyu eksikliği olduğunu göstermektedir. Ya da ne yazık ki, insan koyunu bir kongre izlemeyi alışkanlık gibi çünkü "her zaman böyle yapılır"

Birlikte çalıştığınız şeyleri, birbirleriyle alakalı olsalar bile, birbirlerinden açıkça ve açıkça farklı yapın!

Bunu yapmak için çok iyi bir neden olmadan büyük küçük harf duyarsızlığı yaratmamalısınız. Örneğin, Unicode ile vaka karşılaştırmalarıyla başa çıkmak bir orospu olabilir. İhtiyaçlarının çok farklı olması nedeniyle, eski dillerin durum duyarlılığı (veya eksikliği) önemsizdir .

Bu dönemde programcılar büyük / küçük harf duyarlılığı bekliyorlar.

Büyük küçük harf duyarlılığı kodu daha okunaklı hale getirir ve programlamayı kolaylaştırır.

• İnsanlar karışık durumun uygun kullanımını okumayı daha kolay buluyorlar .

• CamelCase'e, farklı harflerle aynı kelimenin ilgili şeylere atıfta bulunabileceği şekilde izin verir / teşvik eder: Car car; Böylece adlandırılan değişken cartürden yaratılır Car.

• ALL_CAPS_WITH_UNDERSCORES, birçok dilde sözleşmeye göre sabitleri belirtir

• all_lower_with_underscores üye değişkenler veya başka bir şey için kullanılabilir.

• Tüm modern programlama araçları (kaynak kontrolü, editörler, diff, grep, vb.) Büyük / küçük harf duyarlılığı için tasarlanmıştır. Sonsuza dek büyük / küçük harf duyarsız bir dil yaparsanız, programcıların alması gereken araçlarla ilgili sorunlar yaşıyorsanız sonsuza dek yaşayacaksınız.

• Dil yorumlanacaksa, kodun duyarsız ayrıştırılması durumunda performans cezası olabilir.

• İngilizce olmayan karakterlerden ne haber? Şimdi, Kıpti, Çince ve Hintçe'yi asla desteklemeyeceğine mi karar veriyorsun? Dilinizi her şeyi UTF-8 olarak varsayılan olarak ayarlamanızı şiddetle tavsiye ediyorum ve bu, büyük veya küçük harf eşdeğeri olmayan karakterleri olan bazı dilleri destekliyor. Bu karakterleri anahtar kelimelerinizde kullanmayacaksınız, ancak çeşitli araçlardaki büyük harf duyarlılığını kapatmaya başladığınızda (örneğin, dosyalardaki şeyleri bulmak için), bazı gerçeküstü ve muhtemelen hoş olmayan deneyimler yaşarsınız.

Fayda ne? Bahsettiğiniz 3 dil, 1970'lerden veya daha önceki dillerden. Hiçbir modern dil bunu yapmaz.

Öte yandan, son kullanıcıyı gerçekten mutlu eden her şey dünyaya biraz ışık tutuyor. Kullanıcı mutluluğunu gerçekten etkileyecekse, o zaman yapmanız gerekir.

Son kullanıcılar için gerçekten kolaylaştırmak istiyorsanız, büyük / küçük harfe duyarlılık / duyarsızlıktan daha iyisini yapabilirsiniz - Scratch'a bir göz atın ! Birkaç tane daha az karikatür kedi ve daha fazla iş dostu renkler ve şimdiye kadar gördüğüm en cana yakın dilin var - ve hiçbir şey yazmanıza gerek yok! Sadece bir düşünce.