لماذا لا نزال نبرمج باستخدام الملفات المسطحة؟[مغلق]

https://stackoverflow.com/questions/160633

flat-file

03-07-2019
|

سؤال

لماذا تعد الملفات النصية المسطحة أحدث التقنيات لتمثيل كود المصدر؟

بالتأكيد - يحتاج المعالج المسبق والمترجم إلى رؤية تمثيل ثابت للملف، ولكن يمكن إنشاؤه بسهولة.

يبدو لي أن بعض أشكال XML أو البيانات الثنائية يمكن أن تمثل الكثير من الأفكار التي يصعب تتبعها، وإلا.

على سبيل المثال، يمكنك تضمين مخططات UML مباشرة في التعليمات البرمجية الخاصة بك.ويمكن إنشاؤها بشكل شبه تلقائي، وتعليقها بواسطة المطورين لتسليط الضوء على الجوانب المهمة في التصميم.مخططات التفاعل على وجه الخصوص.حسنًا، قد يؤدي تضمين أي رسم للمستخدم إلى جعل الأمور أكثر وضوحًا.

فكرة أخرى هي تضمين التعليقات من مراجعات الكود مباشرة في الكود.

يمكن أن تكون هناك جميع أنواع المساعدات لتسهيل دمج الفروع المتعددة.

ما يثير شغفي ليس فقط تتبع تغطية التعليمات البرمجية، ولكن أيضًا النظر في أجزاء التعليمات البرمجية التي يغطيها الاختبار الآلي.الجزء الصعب هو تتبع هذا الرمز، حتى بعد تعديل المصدر.على سبيل المثال، نقل وظيفة من ملف إلى آخر، وما إلى ذلك.يمكن القيام بذلك باستخدام المعرفات الفريدة العمومية (GUIDs)، ولكنها تكون متطفلة إلى حد ما بحيث يتم تضمينها مباشرة في الملف النصي.وفي تنسيق ملف غني، يمكن أن تكون تلقائية وغير مزعجة.

فلماذا لا توجد بيئة تطوير متكاملة (على أي حال، على حد علمي) تسمح لك بالعمل مع التعليمات البرمجية بهذه الطريقة؟

يحرر: في 7 أكتوبر 2009.

لقد تعلق معظمكم بشدة بكلمة "ثنائي" في سؤالي.أنا أسحبه.صورة XML، مع الحد الأدنى من ترميز التعليمات البرمجية الخاصة بك.في اللحظة التي تسبق تسليمها إلى المعالج المسبق أو المترجم العادي، تقوم بإزالة كافة علامات XML وتمرير كود المصدر فقط.في هذا النموذج، لا يزال بإمكانك القيام بكل الأشياء العادية للملف:diff، وmerge، وتحرير، والعمل بها في محرر بسيط وبسيط، وإدخالها في آلاف الأدوات.نعم، إن عمليات الاختلاف والدمج والتحرير، مباشرةً باستخدام الحد الأدنى من علامات XML، تصبح أكثر تعقيدًا بعض الشيء.لكنني أعتقد أن القيمة يمكن أن تكون هائلة.

إذا كان هناك بيئة تطوير متكاملة (IDE) تحترم XML بالكامل، فيمكنك إضافة أكثر بكثير مما يمكننا القيام به اليوم.

على سبيل المثال، يمكن لتعليقات Doxygen الخاصة بك أن تكون في الواقع ينظر مثل الناتج D Oxygen النهائي.

عندما يريد شخص ما إجراء مراجعة للتعليمات البرمجية، مثل Code Collaborator، يمكنه ترميز التعليمات البرمجية المصدر في مكانها.

يمكن أيضًا إخفاء XML خلف التعليقات.

// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>

وبعد ذلك، إذا كنت تريد استخدام vi أو emacs، يمكنك فقط تخطي التعليقات.

إذا كنت أرغب في استخدام محرر متطور، فيمكنني رؤية ذلك من خلال حوالي اثنتي عشرة طريقة مفيدة مختلفة.

هذه هي فكرتي التقريبية.إنها ليست "لبنات بناء" للصور التي تسحبها على الشاشة...أنا لست بهذا الجنون.:)

المحلول

يمكنك فرقهم
يمكنك دمجها
يمكن لأي شخص تحريرها
فهي بسيطة وسهلة التعامل معها
فهي متاحة عالميًا لآلاف الأدوات

نصائح أخرى

في رأيي، وتفوق أي فوائد محتملة من قبل تعادلهما إلى أداة معينة.

ومع مصدر النص العادي (الذي يبدو أنه ما نناقش، بدلا من <م> ملفات مسطحة في حد ذاته) I يمكن لصق قطع في رسالة بريد إلكتروني، واستخدام أنظمة بسيطة التحكم في الإصدار (مهم جدا! )، كتابة التعليمات البرمجية في التعليقات على تجاوز المكدس، استخدم واحد من ألف برامج تحرير النصوص على أي عدد من المنصات، وما إلى ذلك.

ومع بعض التمثيل ثنائي من التعليمات البرمجية، ولست بحاجة لاستخدام محرر متخصص لعرض أو تحريره. حتى إذا كان يمكن أن تنتج تمثيل يستند إلى نص، لا يمكنك لفة مسلي العودة التغييرات في النسخة الأساسية.

ومن Smalltalk هو البيئة الصورة القائمة. انت لم تعد تعمل مع رمز في ملف على القرص. كنت تعمل مع وتعديل الكائنات حقيقية في وقت التشغيل. فإنه لا يزال النص ولكن لا يتم تخزين الطبقات في ملفات قابلة للقراءة الإنسان. وبدلا من ذلك يتم تخزين الذاكرة كائن كامل (الصورة) على ملف في تنسيق ثنائي.

ولكن اكبر شكاوى من أولئك الذين يحاولون الخروج من Smalltalk لأنه لا يستخدم الملفات. ومعظم الأدوات التي تعتمد على الملف الذي لدينا (همة، ايماكس، كسوف، vs.net، أدوات يونيكس) يجب أن يتم التخلي عنها لصالح أدوات من Smalltalk الخاصة. ليس ذلك الأدوات المتوفرة في من Smalltalk في أقل شأنا. كان مختلفا تماما.

وماذا مقالات مكتوبة في النص؟ لماذا وثائق قانونية مكتوبة في النص؟ لماذا روايات الخيال مكتوبة في النص؟ لأن النص هو أفضل شكل واحد - للأشخاص - من استمرار أفكارهم

والنص هو كيف يفكر الناس، تمثل، وفهم، وتستمر <م> المفاهيم - ومن التعقيدات، الهرمية، والعلاقات المتبادلة

والبرامج اللثغة ليست ملفات مسطحة. هم التسلسل هياكل البيانات. هذا الرمز كما هو والبيانات فكرة قديمة، وفي الواقع واحدة من أعظم فكرة في علوم الكمبيوتر.

<؟ XML الإصدار = "1.0" ترميز = "UTF-8"؟> <رمز> ملفات مسطحة هي أسهل للقراءة.

إليكم السبب:

انسان قارئ.وهذا يجعل اكتشاف الخطأ أسهل بكثير، في كل من الملف وطريقة التحليل.ويمكن أيضا أن تقرأ بصوت عال.وهذا أمر لا يمكنك الحصول عليه باستخدام XML، وقد يحدث فرقًا، خاصة في دعم العملاء.
التأمين ضد التقادم.طالما أن التعبير العادي موجود، فمن الممكن كتابة محلل جيد جدًا في بضعة أسطر فقط من التعليمات البرمجية.
تَأثِير.يمكن لكل شيء موجود تقريبًا، بدءًا من أنظمة التحكم في المراجعة وحتى المحررين وحتى التصفية، فحص الملفات الثابتة ودمجها وتشغيلها.قد يكون دمج XML بمثابة فوضى.
القدرة على دمجها بسهولة مع أدوات UNIX، مثل grep أو Cut أو sed.

وانها سؤال جيد. FWIW، وأنا أحب أن أرى أداة إدارة رمز أسلوب ويكي. فإن كل وحدة وظيفية لديها صفحة ويكي الخاصة بها. أدوات إنشاء سحب معا شفرة المصدر من ويكي. سيكون هناك صفحة "مناقشة" مرتبط إلى تلك الصفحة، حيث يمكن للناس أن يجادل حول الخوارزميات، واجهات برمجة التطبيقات ومثل هذه.

وهيك، فإنه لن يكون من الصعب أن الإختراق واحدة من تطبيق المعرفة موجودة مسبقا. أي محتجزي ...؟

ومن المفارقات أن هناك برمجة التركيبات التي تستخدم بالضبط ما تصفون.

وعلى سبيل المثال، SQL Server تكامل خدمات، والتي تنطوي على الترميز تدفق المنطق عن طريق سحب المكونات في سطح التصميم المرئي، يتم حفظها كملفات XML يصف نهاية بالضبط الظهر.

في مباحث أمن الدولة جهة أخرى من الصعب جدا أن السيطرة المصدر. كما أنه من الصعب إلى حد ما لتصميم أي نوع من المنطق معقدة إليه: إذا كنت في حاجة الى أكثر قليلا "السيطرة"، ستحتاج إلى رمز رمز VB.NET إلى المكون، وهو ما يقودنا <م> العودة إلى حيث بدأنا.

وأعتقد أنه، كما المبرمج، يجب النظر في حقيقة أن كل حل لمشكلة هناك عواقب التي تتبع. لم يستطع كل شيء (ويجادل البعض، يجب) أن تكون ممثلة في UML. ليس كل شيء يمكن أن تكون ممثلة بصريا. لا يمكن تبسيط كل شيء بما فيه الكفاية ليكون لها تمثيل ملف ثنائي ثابت.

وأن يقال، وأود أن نفترض أن مساوئ محيلة الرمز إلى صيغ ثنائية (معظمها سوف تميل إلى أن تكون الملكية) outweight بكثير من مزايا وجود لهم في نص عادي.

سوف

وIMHO، XML والأشكال ثنائية تكون فوضى تامة، وسوف لا يعطي أي فائدة كبيرة.

وOTOH، وهي فكرة ذات الصلة سيكون لكتابة في قاعدة بيانات، وربما وظيفة واحدة لكل سجل، أو ربما بنية هرمية. وIDE التي تم إنشاؤها حول هذا المفهوم قد يجعل التنقل مصدر أكثر طبيعية، وأسهل لإخفاء أي شيء لا يمت بصلة إلى رمز كنت تقرأ في لحظة معينة.

لقد حاول الأشخاص لفترة طويلة إنشاء بيئة تحرير تتجاوز الملف الثابت، وقد فشل الجميع إلى حد ما.أقرب ما رأيته كان نموذجًا أوليًا للبرمجة المتعمدة لتشارلز سيموني ولكن بعد ذلك تم تخفيضه إلى أداة إنشاء DSL مرئية.

بغض النظر عن كيفية تخزين الكود أو تمثيله في الذاكرة، في النهاية يجب أن يكون قابلاً للعرض والتعديل كنص (دون أن يتغير التنسيق عليك) لأن هذه هي الطريقة الأسهل التي نعرفها للتعبير عن معظم المفاهيم المجردة اللازمة لحل المشكلات عن طريق البرمجة.

مع الملفات المسطحة، يمكنك الحصول على هذا مجانًا وسيعمل أي محرر نص قديم عادي (مع دعم ترميز الأحرف الصحيح).

وستيف ماكونيل ديه ذلك الحق، كما هو الحال دائما - أن تكتب برامج للمبرمجين الآخرين (بما في ذلك بنفسك)، وليس لأجهزة الكمبيوتر

وقال ذلك، يجب أن مايكروسوفت البصرية ستوديو إدارة داخليا رمز تكتب في شكل منظم جدا، أو أنك لن تكون قادرة على القيام أشياء مثل "البحث عن كافة المراجع" أو إعادة تسمية أو إعادة عامل المتغيرات والأساليب بهذه السهولة . سأكون مهتما إذا كان أي شخص روابط لكيفية حدوث ذلك.

في الواقع، منذ ما يقرب من 10 عاما، حاول النموذج تشارلز سيموني في وقت مبكر للبرمجة متعمدة لتجاوز ملف ثابت إلى تمثيل شجرة من التعليمات البرمجية التي يمكن تصور بطرق مختلفة. نظريا، يمكن لخبير نطاق وPM، ومهندس البرمجيات ترى كل (وقطعة معا) رمز التطبيق في الطرق التي كانت مفيدة لهم، ويمكن أن يبنى المنتجات على تسلسل هرمي من "نوايا" التقريرية، وحفر أسفل إلى منخفض رمز مستوى فقط حسب الحاجة.

وETA (لكل طلب في الأسئلة) وهناك نسخة من واحد من أوراقه في وقت مبكر على هذا في موقع ويب Microsoft البحوث. للأسف، منذ غادر سيموني MS لتأسيس شركة منفصلة قبل عدة سنوات، وأنا لا أعتقد أن النموذج لا تزال متاحة للتحميل. رأيت بعض العروض مرة عندما كنت في شركة مايكروسوفت، لكنني لست متأكدا كيف على نطاق واسع وزعت له النموذج الأولي في وقت مبكر.

وشركته، IntentSoft لا يزال الهدوء قليلا عن ما كنت تخطط لتسليمها إلى السوق ، إذا كان أي شيء، ولكن بعض الاشياء في وقت مبكر التي خرجت من MSR كان مثيرا للاهتمام إلى حد ما.

وكان النموذج تخزين بعض تنسيق ثنائي، ولكنني لست متأكدا كم من تلك التفاصيل تم الكشف عنها خلال مشروع MSR، وأنا متأكد من أن بعض الأمور قد تغيرت منذ التنفيذ في وقت مبكر.

لماذا حكم ملفات نصية؟ بسبب اختبار ماكلروي و. ومن الأهمية بمكان أن يكون الناتج من برنامج واحد يكون مقبولا كما شفرة المصدر لآخر، وملفات نصية هي أبسط شيء يعمل.

ابفيف و <لأ href = "http://www.mathworks.com/products / SIMULINK / "يختلط =" نوفولو noreferrer "> SIMULINK هما بيئات البرمجة الرسومية. كلاهما شعبية في حقولهم (التواصل على الأجهزة من جهاز كمبيوتر، ونمذجة أنظمة التحكم، على التوالي)، ولكنها لا تستخدم كثيرا خارج تلك الحقول. لقد عملت مع الناس الذين كانوا جماهير كبيرة على حد سواء، ولكن لم يحصل الى لهم نفسي.

ولقد ذكرتم بأنه ينبغي لنا أن نستخدم "شكلا من أشكال XML"؟ ما رأيك XHTML و XAML هي؟

وأيضا XML لا يزال مجرد ملف ثابت.

والعادات القديمة لا تموت بسهولة، وأعتقد.

وحتى وقت قريب، لم تكن هناك العديد من نوعية جيدة، والأداء العالي، المكتبات على نطاق واسع المتاحة للتخزين العام من البيانات المنظمة. وأود أن قاطع <م> لا وضع XML في هذه الفئة حتى اليوم - مطول جدا، مكثفة جدا لعملية، صعب جدا

وهذه الأيام، بلدي الشيء المفضل لاستخدامها في البيانات التي لا تحتاج إلى أن يكون الإنسان وreadableis سكليتي و جعل قاعدة البيانات. حتى انها سهلة للغاية لتضمين قاعدة بيانات كاملة المواصفات SQL في أي التطبيق ... هناك ربط لC، بيرل، بيثون، PHP، الخ ... وانها مفتوحة المصدر وحقا سريعة وموثوقة وخفيفة الوزن.

I <3 سكليتي.

أي شخص حاول من أي وقت مضى الرياضيات?

الصورة أعلاه مأخوذة من إصدار قديم ولكنها كانت أفضل ما يمكن أن تقدمه لي Google.

على أية حال...قارن المعادلة الأولى هناك Math.Integrate(1/(Math.Pow("x",3)-1), "x") كما لو كان عليك الكتابة إذا كنت تقوم بالبرمجة باستخدام نص عادي في معظم اللغات الشائعة.إن قراءة التمثيل الرياضي أسهل بكثير، ولا تزال هذه معادلة صغيرة جدًا.

ونعم، يمكنك إدخال الكود ونسخه ولصقه كنص عادي إذا كنت تريد ذلك.

انظر إليه باعتباره الجيل القادم تسليط الضوء على تركيب.أراهن أن هناك الكثير من الأشياء الأخرى غير الرياضيات التي يمكن أن تستفيد من هذا النوع من التمثيل.

وهذا واضح جدا لماذا سهل النص هو الملك. ولكن من الواضح أيضا لماذا شكل منظم سيكون أفضل.

واحد فقط على سبيل المثال: إذا قمت بإعادة تسمية الطريقة، سيكون لديك أداة تحكم فرق / دمج / المصدر أن تكون قادرة على أن تقول أن شيئا واحدا فقط قد تغير. إن الأدوات التي نستخدمها اليوم تظهر قائمة طويلة من التغييرات، واحد لكل مكان والملف الذي كان يسمى أسلوب أو المعلنة.

و(بالمناسبة، هذه الوظيفة لا يجيب على السؤال كما كنت قد لاحظت)

والاتجاه ونحن نشهد حول لDSL هي أول ما يتبادر إلى الذهن عند قراءة سؤالك. كانت المشكلة أن هناك لا وجود له علاقة 1 إلى 1 بين النماذج (مثل UML) والتنفيذ. مايكروسوفت وغيرها تعمل على الوصول إلى هناك، بحيث يمكنك إنشاء التطبيق كشيء UML تشبه، ومن ثم يمكن إنشاء رمز. والشيء المهم - كما كنت تختار لتغيير التعليمات البرمجية، سيعكس نموذج هذا مرة أخرى

ويندوز مؤسسة سير العمل هو مثال جيد جدا. السبب هناك ملفات مسطحة و / أو XML في الخلفية، ولكن يمكنك عادة في نهاية المطاف تحديد منطق عملك في أداة التزامن. وهذا هو بارد جدا!

ونحن بحاجة إلى المزيد من "المصانع البرمجيات" التفكير، وسوف نرى تجربة IDE الأكثر ثراء في المستقبل، ولكن طالما أجهزة الكمبيوتر تعمل على أصفار ومنها، ملفات نصية المسطحة يمكن و(ربما) سوف يكون دائما مرحلة وسيطة . كما ذكر أن العديد من الناس بالفعل، ملفات نصية بسيطة مرنة للغاية.

ولقد تساءل بحزن الشيء نفسه، كما هو موضح في جواب: ما هي الأداة / التطبيق / أيا كان هل ترغب موجودة؟

ولئن كان من السهل أن نتصور عددا كبيرا من الفوائد وأعتقد أن أكبر عقبة التي سيتعين التصدي له هو أن لا أحد قد تنتج بديلا مجديا.

وعندما يفكر الناس في بدائل لتخزين مصدر كنص يبدو أنهم يعتقدون في كثير من الأحيان على الفور من حيث رسوم بيانية (أنا أشير هنا إلى المنتجات التجارية التي كانت متاحة - مثل HP مخروطى المقطع). وإذا نظرنا إلى تجربة الناس مثل مصممي FPGA، ونحن نرى أن البرمجة (حصرا) بيانيا فقط لا يعمل - وبالتالي لغات مثل فيريلوج وVHDL

ولكن لا أرى أن تخزين مصدر تحتاج بالضرورة أن تكون ملزمة لطريقة كتابته في المقام الأول. دخول مصدر يمكن القيام به إلى حد كبير كنص - وهو ما يعني أن قضايا نسخ / لصق لا يزال من الممكن تحقيقه. ولكن أرى أيضا أنه من خلال السماح للدمج ومستواها السابق الذي يتعين القيام به على أساس tokenised الفوقية مصدر نتمكن من تحقيق أدوات أكثر دقة وأكثر قوة التلاعب.

يستخدم

وFoxPro مرئي بنية الجدول DBF لتخزين رمز والفوقية للالنماذج والتقارير، يبس الطبقة وغيرها وهذه هي الملفات الثنائية. لأنه يخزن أيضا التعليمات البرمجية في ملفات PRG أن الملفات النص الفعلي ...

والميزة الوحيدة أرى هو القدرة على استخدام المدمج في VFP لغة البيانات لإجراء عمليات البحث التعليمات البرمجية على تلك الملفات ... غير أنه من مسؤولية المنظمة البحرية الدولية. على الأقل مرة واحدة كل بضعة أشهر، واحد من هذه الملفات إعطابها دون سبب واضح. التكامل مع التحكم بالمصادر وبيانات الاختلاف مؤلمة جدا كذلك. هناك حلول لهذه، ولكنها تنطوي على تحويل الملف إلى نص مؤقتا!

لمثال من اللغة التي يلغي التقليدية النص البرمجة، راجع الحمم اللغة .

وآخر شيء أنيق اكتشفت مؤخرا هو subtext2 (و<لأ href = "http://subtextual.org /subtext2.html "يختلط =" نوفولو noreferrer "> فيديو تجريبي).

ومدونة قواعد البرنامج تحديد هيكل التي ستنشأ مع أكس أو تنسيق ثنائي. لغة البرمجة الخاصة بك هي تمثيل أكثر مباشرة من هيكل البرنامج الخاص بك من وXML أو تمثيل ثنائي سيكون. هل لاحظت كيف يسيء التصرف ورد عليك كما كنت تعطي هيكل إلى المستند. برفكت على الأقل سوف "تكشف عن رموز" للسماح لك لمعرفة ما يكمن تحت المستند. ملفات مسطح تفعل نفس الشيء للبرنامج.

وفكرة أنيق ل. أما أنا فقد تساءل على نطاق أصغر ... أصغر من ذلك بكثير، لماذا لا يمكن IDE X توليد هذا أو ذاك.

وأنا لا أعرف إذا أنا قادر كمبرمج بعد لتطوير شيء ما بارد ومعقدة مثل الحديث الخاص حول أو ما أفكر، ولكن أود أن تكون مهتمة في المحاولة.

وربما تبدأ مع بعض الإضافات ل.NET، الكسوف، نتبيانس، وهلم جرا؟ اظهار ما يمكن القيام به، وتبدأ اتجاها جديدا في الترميز.

وأعتقد أن جانبا آخر من هذا هو أن الرمز هو المهم. وهو ما سوف يتم تنفيذها. على سبيل المثال، في المثال UML الخاص بك، وأود أن أعتقد بدلا من الاضطرار UML (تم إنشاؤه يفترض في بعض المحرر، لا تتصل مباشرة "رمز") المدرجة في بك "فقاعة مصدر" ستكون عديمة الفائدة تقريبا. أفضل بكثير أن يكون لديك UML ولدت مباشرة من التعليمات البرمجية الخاصة بك، لذلك يصف حالة بالضبط هو رمز في كأداة لفهم التعليمات البرمجية، بدلا من أن تكون تذكير بما كان ينبغي أن يكون رمز.

لقد تم القيام بذلك لسنوات بشأن الأدوات وثيقة الآلي. في حين التعليقات مبرمج الفعلي ولدت في التعليمات البرمجية قد تحصل متزامنة مع رمز، أدوات مثل جافادوك وما شابه ذلك بإخلاص تمثل الأساليب على كائن، والعودة أنواع الحجج، الخ وهي تمثل لهم لأنها موجودة فعلا، وليس كما بعض الأداة التي خرجت من اجتماعات تصميم لا نهاية لها.

ويبدو لي أنه إذا كنت يمكن أن تضيف تعسفا التحف عشوائية لبعض "النقطة مصدر"، وهذه من المرجح ان يكون قديما وأقل من المفيد على الفور. إذا كنت يمكن أن تولد مثل هذه التحف مباشرة من التعليمات البرمجية، ثم جهد صغير للحصول على عملية الإنشاء الخاصة بك للقيام بذلك هو أفضل بكثير من المزالق التي سبق ذكرها من الابتعاد عن الملفات المصدر نص عادي.

وذات صلة لهذا، وهو شرح لماذا 'د ترغب في استخدام نص عادي UML أداة ( UMLGraph ) ويبدو أن تطبق بالتساوي تقريبا وكذلك لماذا تريد ملفات مصدر نص عادي.

وهذا قد لا تجيب على سؤالك بالضبط ولكن هنا هو محرر يسمح لها وجهة نظر أعلى من التعليمات البرمجية: http://webpages.charter.net/edreamleo/front.html

وأعتقد أن السبب لماذا يتم استخدام ملفات النص في التنمية هو أن تكون عالمية ضد أدوات التنمية المختلفة. يمكنك أن تبحث داخل أو حتى إصلاح بعض الأخطاء باستخدام محرر نصوص بسيط (لا يمكنك أن تفعل ذلك في ملف ثنائي لأنك لا تعرف كيف يمكن لأي إصلاح من شأنه أن يدمر بيانات أخرى). وهذا لا يعني، مع ذلك، أن الملفات النصية هي الأفضل لتحقيق هذه الأغراض.

وبطبيعة الحال، يمكنك مهرجان دبي السينمائي الدولي ودمجها. ولكن هذا لا يعني أن / أداة دمج فرق فهم بنية متميزة من البيانات المشفرة بواسطة هذا الملف النصي. يمكنك أن تفعل فرق / دمج، ولكن (ينظر خصوصا في ملفات XML) فإن أداة فرق لا تظهر لك الفروق بشكل صحيح، وهذا هو، وسوف تظهر لك حيث تختلف الملفات والتي أجزاء من البيانات أداة "يفكر" هي نفسها. لكنها لن تظهر لك الاختلافات في بنية ملف XML - سيكون مجرد تطابق الخطوط التي تبدو متشابهة

وبغض النظر عما إذا كنا تستخدمه الملفات الثنائية أو ملفات نصية، فإنه من الأفضل دائما أن فرق / دمج أدوات رعاية من بنية البيانات يمثل هذا الملف بدلا من الخطوط والحروف. لC ++ أو ملفات جافا، على سبيل المثال، تفيد بأن بعض المعرف تغيير اسمها التقرير أن بعض .تم محاطة إضافية إذا () {}، ولكن، من ناحية أخرى، تجاهل تغييرات في المسافات البادئة أو أحرف EOL. ان النهج الأفضل أن تتم قراءة ملف في الهياكل الداخلية وملقاة باستخدام قواعد التنسيق المحددة. بهذه الطريقة سوف تبذل فرق جي من خلال الهياكل الداخلية ونتيجة دمج سيتم إنشاء من البنية الداخلية المدمجة.

وتتكون

والبرامج الحديثة من قطع مسطحة، ولكن هل هي شقة؟ هناك usings، ويشمل ذلك، والمكتبات من الكائنات، الخ مكالمة وظيفة عادية هو نظرة خاطفة إلى مكان مختلف. منطق ليست مسطحة، وذلك بسبب وجود مواضيع متعددة، الخ.

ولدي نفس الرؤية! أنا حقا أتمنى أن هذا موجود.

وقد ترغب في إلقاء نظرة على قلعة، وهي لغة البحث من قبل الشمس. لديه دعم خاص لالصيغ في شفرة المصدر. الاقتباس أدناه من ويكيبيديا

<اقتباس فقرة>

ويجري حاليا تصميم قلعة من البداية أن يكون نحوي متعددة الشكل. شفرة المصدر يمكن أن يكون كما تصدر نص ASCII، في Unicode، أو كصورة prettied. وهذا سيسمح للحصول على الدعم من الرموز الرياضية وغيرها من الرموز في المقدمة الإخراج لتسهيل القراءة.

والسبب الرئيسي لاستمرار وجود النص كمصدر هو عدم وجود لبوويرتولس، والرقابة مثل نسخة، لتاريخ غير نصية. وذلك بناء على تجربتي في العمل مع من Smalltalk، حيث يتم الاحتفاظ عادي رمز بايت في نواة تفريغ كل وقت. في نظام غير نصية، مع أدوات اليوم، فريق التطوير هو كابوس.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow